# Accounts and Permissions

An account is an account of a member or a group of members DAO VIZ, with which operations are performed in the VIZ blockchain.

When an account is created, it is assigned a unique name of length from 2 (opens new window) selected by the participant as an identifier to 25 (opens new window) characters Latin alphabet. Two-character accounts are reserved for the very first VIZ members and are no longer assigned. You cannot change the account name after creation.

Account holders can create accounts of the "second level", and those, in turn, the third, etc., which are separated from the main account (and subsequent) by a dot. For example, the account @name (and only he) can create the account @subname.name, which, in turn, @subsubname.subname.name, etc.

An account has four key pairs (public and private):

master key,
active key,
regular key,
communication key.

Each public key must be generated from different private keys using an elliptic cryptography algorithm for the curve secp256k1 (opens new window) (the same curve is used in Bitcoin).

The table below shows the parameters for secp256k1*

Parameter	Value
p	0xffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f
a	0
b	7
Gx	0x79be667e f9dcbbac 55a06295 ce870b07 029bfcdb 2dce28d9 59f2815b 16f81798
Gy	0x483ada77 26a3c465 5da4fbfc 0e1108a8 fd17b448 a6855419 9c47d08f fb10d4b8
n	0xffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141
h	1

Each time a transaction is sent on behalf of an account, the user must sign it using the ECDSA (opens new window) algorithm with one of three private keys, which corresponds to the main, active or regular public key. A communicative key cannot be used to send transactions. It is used to encrypt messages, for example, in a token transfer note. When signing, it should be borne in mind that each key has its own access level, that is, different keys are responsible for different types of transactions.

The table below describes all the keys and operations that can be performed with their help

Key	Permissions
Regular	Sending custom-transactions, rewarding users, changing account metadata, any actions with committee.
Active	Everything that can be done using a regular key, as well as operations with assets and voting for witnesses.
Master	Everything that can be done with regular and active keys, as well as replacement of all keys.
Memo	Does not allow signing transactions, but it can be used to classify messages, for example, encrypt using the ECDH (opens new window) algorithm when transferring tokens

# Account with multiple users

If the user knows the master private key of a particular account, then he can add other users to the account.

There are two options for how to do this. The first one is to add another key to the account (master, active or regular) and transfer it to the second user. The second is to register a main, active or regular role for another account in your account, that is, link one account to another. The difference between a role and keys is that the owners of the linked account will use their private keys to sign transactions.

Note that linking accounts is a more flexible way of adding users to the main account, since by linking one account, you can immediately assign permissions to a group of people.

It should be borne in mind that the user who received an additional key, or an account that is assigned one of the three roles, when signing transactions on behalf of the main account, is limited only by the access level of the key or role. That is, if a user is assigned a master key or if the account is assigned a main role, then both the user and the account will be able to determine the access levels to the main account for other members of the VIZ DAO, and even restrict access to the original owner of the account.

# Multi-signature

To avoid abuse of authority, you can set a weight threshold for each access level, upon reaching which you can send a transaction, and set a weight for each user or linked account. Thus, to send a transaction, a signature of several users will be required, so that the sum of their weights is not less than the weight threshold. This signature scheme is called multisignature.

# Multisignature examples

Let three users be registered in an account with a weight threshold of 100: Alice, Max and Bob. Bob has a weight of 25, Max also has 25, and Alice has 50. Then Bob needs Alice and Max signatures to send the transaction, because only in this case the total weight of the signers will be equal to the weight threshold of the account 100. Max or Alice must do the same. to send a transaction on behalf of the account. Thus, no one will be able to send a transaction without the consent of all participants, which avoids abuse of authority by any of the users.

If, with the same distribution of the weights of the multisignature participants, the weight threshold is set at 75, then the signature of Alice (weight 50) and any of the other multisignature participants (with weight 25) is sufficient for the transaction. At the same time, Max (25) and Bob (25) will not be able to sign the transaction without Alice (50).

# Registration

To create a new account in VIZ, you need to send a special transaction (account_create), which will register a new account. This transaction specifies:

the name of the new account (name);
name of the referrer account (referrer) - optional;
account metadata (json_metadata) - optional;
four public keys: master (master_authority), active (active_authority), regular (regular_authority), communicative (memo).

Instead of keys, you can link existing accounts to roles of the same name. True, in the latter case, you still have to prescribe a communicative key, since there is no role for it.

The sender of the transaction must pay for the creation of an account an amount not less than indicated by the witnesses. All liquid tokens that the registrar pays will be converted into shares of the new account.

In addition to the direct transfer of liquid tokens, there are two more ways to create an account: registration through delegation of a share and creation through an invite code.

In order not to spend liquid tokens, the registrar can create a new account by delegation. To do this, he must also send a transaction, but indicate in it not the number of liquid tokens that he is ready to spend (transfer to the share of the new account), but the number of share tokens that he is ready to delegate to the new account.

The value of all delegated shares in viz must be no less than indicated by witnesses.

Along with delegation, the registrar can spend liquid tokens, they will also be converted into shares of the new account, but the transaction price will not be affected, the account will be created either for viz or for shares.

If the number of translated viz is enough for registration for liquid tokens, then the account will be created for viz, if not enough, then for delegated shares. If the number of delegated shares is also insufficient, the account will not be created.

The registrar will be able to revoke delegated tokens by default after 28 days or after another period specified by the witnesses.

If the registrar tries to revoke shares earlier than the specified period, they will be debited from the new account, but will be frozen until 28 days have passed since the registration. In case of freezing, neither the registrar nor the created account can use the share tokens.

# Register with bearer check

Read more about checks in the section: Bearer Checks. *

Another convenient way to create a new account is to pay for registration using a check. For this, a future VIZ participant must purchase (buy or receive as a gift) a VIZ check for an amount not less than indicated by the witnesses as a fee for creating an account.

The owner of the check, using the application or directly sends a special transaction (invite_registration) to the blockchain, indicating the private key of the check and the public future master key of the account. This transaction will register a new account by spending tokens from the check. All tokens from the check will be converted into shares of the new account.

If a person already has an account, then he can sign the transaction using his account and its private active key. If he does not have an account, he can send a transaction using the @invite account, which belongs to the blockchain, signing it with the private key 5KcfoRuDfkhrLCxVcE9x51J6KN9aM9fpb78tLrvvFckxVV6FyFW.

# Anonymous accounts

To create anonymous accounts, a special @anonymous account was built into the blockchain. To register an account, it is necessary to transfer to it viz tokens with a volume of no less than indicated by the witnesses, attach a note with the name of the new account and its public key to the transfer (the private key must be kept in a safe place and no one do not transmit). The note must match the format

login: key,

where login is the name of the new account, key is its key. The public key, in turn, will be registered as the main, active, regular and communicative.

Another way to create an anonymous account is to specify only the public key for the new account, without a colon (:). When @anonymous receives the transfer, it will create a new account using the @ nX.anonymous scheme, where X is the anonymous account number. The @anonymous number is assigned by itself, each time adding one to the number of already created anonymous accounts.

Anonymous accounts have the same rights as other accounts. And with popular gateways that allow you to transfer funds to other users through their accounts, it will be difficult to identify the owners of anonymous accounts, provided they took precautions to hide their identity. Such gateways can be, for example, exchanges or exchangers.

# Energy

Each account on the blockchain has a supply of energy, which is measured as a percentage. The maximum energy value is 100%, the minimum can be -100%, that is, less than 0%.

Energy is needed to send awards to other users. If there is not enough energy, then the account will not be able to reward the participant with the required amount of tokens, and if the energy is equal to or less than 0%, then the account will not be able to send the reward at all. However, he will still be able to perform other operations on the blockchain, for example, transfer tokens between accounts, vote for witnesses and do whatever he can with 100% energy. Read more about the awards in the section Activity awards.

Energy is wasted in two cases. First, when the account rewards the participant. In this case, the user himself indicates how much energy he wants to spend, and the size of the reward depends on this amount. Second, when the account witnesses shares to another user.

Delegation occurs in two cases: when registering an account through delegation and when delegating a share to an existing account. With any delegation option, the initiator cannot specify the amount of energy that will be spent, but it is directly proportional to the number of shares that will be sent (the more shares are delegated, the more energy will be spent).

The blockchain calculates the amount of energy that will be spent using the formula delegated shares / effective shares * 100%.

Energy is expended instantly, but recovered slowly: 20% of the maximum in 24 hours, 1% in 1 hour 12 minutes (that is, only 0.01% of the energy is restored in 1 second).

# Account data

This section describes the parameters that accounts contain in the form in which the blockchain stores them. This section will be useful for developers who want to have a better understanding of accounts. All parameters are read-only as a snapshot of the account state from the moment the last block entered the blockchain.

To get started, check out the table of information types that blockchain uses:

Type	Example	Range	Description
VIZ asset	"1.000 VIZ"	from 0.001 VIZ	Number of liquid tokens. A string with a decimal number with no more than 3 digits after a period and a mandatory VIZ postscript separated by a space. Example: "1.123 VIZ"
SHARES актив	"1.000000 SHARES"	from 0.000001 SHARES	Number of share tokens. A string with a decimal number with no more than 6 digits after the period and the obligatory SHARES postscript separated by a space. Example: "1.123456 SHARES"
µShares	1000000	from 1	Number of micro share tokens. 1 = 0.000001 SHARES; 1000000 = 1.000000 SHARES. Integer.
Percentage	1000	from 0 до 10000	Percentage in whole number format. 0.01% = 1; 1% = 100; 100% = 10000;
Integer	1		Integer. Numbers that are too large can be represented as a string.
Byte	1		The number of bytes in general numeric format. Values that are too large are written as strings.
μByte			The number of microbytes in a whole number format. Too large values are written as strings. 1 Byte = 1,000,000 μBytes
Time	"2018-09-30T05:58:57"		Time string type in the format "YYYY-MM-DDThh:mm:ss".
JSON	"{"param1":"value"}"		JSON string
Account	"example"		Account name in string format.
Key	"VIZ8XwKjAkG5...."		Public key in string format with "VIZ" prefix.

Added: 1.0.0

Format: Array

An array containing an array of regular keys and an array of accounts associated with the regular role.

Contains account_auths and key_auths.

account_auths and key_auths are included in the * _authority parameters.

# account_auths

Added: 1.0.0

Format: Array of account arrays and their weights.

List of accounts associated with the role and their weights.

Example: account_auths: [['example', 20], ['owner', 50]]

# key_auths

Added: 1.0.0

Format: An array of arrays of keys and their weights.

List of keys and their weights.

Example: key_auths: [['VIZ6cMf37KNdYiqXNfaCf7VFQDuPUWE6z5dw9LYLbSSGg5kAN1RMi', 20], ['VIZ6cMf38KNeYiqXNfsCf7VFQSSDuPUUEk6z1dw]

Deprecated: 2.0.0

Added: 1.0.0

Format: Integer

The number of user comments. Obsolete due to a change in the economic model - rejection of positioning as a blogging platform.

← Bandwidth VIZ checks →

# Accounts and Permissions

# Account with multiple users

# Multi-signature

# Multisignature examples

# Registration

# Registration through share delegation

# Register with bearer check

# Anonymous accounts

# Energy

# Account data

# average_bandwidth

# lifetime_bandwidth

# balance

# vesting_shares

# delegated_vesting_shares

# received_vesting_shares

# next_vesting_withdrawal

# to_withdraw

# withdraw_routes

# vesting_withdraw_rate

# benefactor_awards

# receiver_awards

# vote_count

# created

# custom_sequence

# custom_sequence_block_num

# energy

# id

# name

# json_metadata

# last_account_recovery

# recovery_account

# referrer

# last_account_update

# last_owner_update

# last_owner_update

# witness_votes

# witnesses_voted_for

# witnesses_vote_weight

# proxied_vsf_votes

# proxy

# master_authority

# active_authority

# regular_authority

# account_auths

# key_auths

# memo_key

# awarded_rshares

# curation_rewards

# posting_rewards

# last_post

# last_root_post

# last_vote_time

# content_count

# subcontent_count