Elector

This main discusses the operation of the elector smart contract, how it's debugging, consequences and causes, and the whole role of the elector in the Free TON network. This should be noted that the elector corresponding to the following code in the original TON repository and can be found on github.com

For future it should be noted straight away that each validator node has at least 2 "different" keys, and they change be at every election (in every new validation cycle) in order to maintain confidentiality and security:

* Validators public key - meant to sign blocks in the validation proceses and messages from the validator to the elector;
* Validators ADNL address - is the key (made by hash from the key) of the validators node, but is meant to be used when routing and encrypting/signing messages in the TON network between nodes (lower level ones), see ADNL for more details.

## Public methods of elector

Like in almost any smart contract, the elector consists of public get-methods that help extract data from its data store and present it in a way more or less digestible and usable form for upcoming further processing. Let us consider such methods. Examples of their call are given for the TON OS -CLI utility in general.

It is worth to mention that, due to function-oriented peculiarities of the FunC type of language, in which the elector is written, the *lists* returned back by command execution will look a little strange than we expect. As an given example, let's take a list of these three elements.

The usual familiar look:

```
["element1", "element2", "element3"]
```

Returning look:

```
[["item1",["item2",["item3",null]]]]
```
 where null stands for as the next item in the end of the list. Details of such a feature can be seen on Wikipedia.

### active\_election\_id

**Method parameters**: *<none>*

**Returned back data**: the ID of the current election, or 0 if there are no elections at the current moment

**An example call**: `tonos-cli runget -1:3333333333333333333333333333333333333333333333333333333333 active_election_id`

**Result**:

```
Result: ["0x5f2aa14f"]
```

There is currently an ongoing election with the `5f2aa14f` ID identifier. This identifier is the UNIX time (seconds, UTC) of the end of the currenr validation cycle, in which the elections are being held, in this example is the local time 05.08.2020 12:08:47.

```
Result: ["0x0"]
```

The given back result (`0x0`) says that there are not any elections taking place at the moment.

Implementation of the method can be found at github.com

### participates\_in

**Method parameters**: validator's public key

**Returned data**: the validators made steak with the specified given public key in our case it participates in the current election; 0 if it does not have any

**Saple of call**: `tonos-cli runget -1:3333333333333333333333333333333333333333333333333333333333333333 participates_in 0x31c64b55694c35e496d922561ffed2f980fb6a5f8d6f19133ee301ed9ed3d5a`

**Result:**

```
Result: ["0x1902d7bb38000"]
```

As a result, in this case the validator with the specified public key actually has been successfully submitted his candidacy for the current upcoming elections - the method will return back his submitted volume of steaked tokens `0x1902d7bb38000` (440000000000000 nanotokens = 440 000 tokens).

```
Result: ["0x0"]
```

If no such participant was not registered - the method will return back with `0x0` as a result.

Implementation of the method can be found at github.com

### participant\_list

'*Method Parameters**:** <none>*.

**Returned data**: list of our candidate validators that were registered (submitted) in the current elections; the list contains the candidate validators' all public keys and their stakes ammount

**Example call**: `tonos-cli runget -1:333333333333333333333333333333333333333333333333333333333333333333333333_list`

**Result:**

```
Result: [[["0x2a229b32309aa794bd89b5be44dd5eb8c50febd1f81251864856f911ca32eae","0xf1041edd9000"],[["0x31c64b55694c35e496d922561ffed2f980fb6a5f8d6f19133ee301ed9ed3d5a", "0x1902d7bb38000"],[["0x65206031447b4ac653e56693e192691f48ef987833267ec32bd91af5c82b599","0x8acd72dcc600"],<. ..>
```

A list of the given public keys of validators submitted for the current election, and ammounts of their stacks. Each list item does contain two items (consider also the first item in the candidate validators list):

* Candidate validator given public key `2a229b32309aa794bd89b5be44dd5eb8c50febd1f81251864856f911ca32eae` (it has to be noted that for "full completeness" and the same key length as other entries given it should add `0` to the beginning of code; the most significant digits are omitted);
* The current amount of tokens he has stacked `0xf1041edd9000` (265000000000000 nanotokens = 265,000 tokens).

In the same way and by the same order, the data for all our other candidates who have been already submitted their candidacy for the current elections are listed.

```
Result: [null]
```

The list will reamain empty if there is no current election for now (or if no candidate has yet applied to run for this election).

Implementation of the method can be found at github.com

### participant\_list\_extended

'*Method Parameters**:** <none>*.

**Returned back data**: list of our candidate validators registered (submitted) in the current upcoming election; the list contains of the all candidate validators' public keys, their stacks ammount, the values of max-factor, wallet address ID (from which the current election application was submitted), ADNL address of the validator ran node; the list is mostly similar to the one returned by `participant_list`, but contains way more data

**Example call**: `tonos-cli runget -1:33333333333333333333333333333333333333333333333333333333333333 participant_list_extended`

**Result:**

```
Result: ["0x5f2ac14f","0x5f2aa14f","0x9184e72a000","0xdc4962e68d800",[["0x2a229b32309aa794bd89b5be44dd5eb8c50febd1f81251864856f911ca32eae", ["0xf1041edd9000","0x30000","0x315cf279d9503e0da1007aa3b08ed3dac3dc1b32ba9a1c0163dd4a0a8c82fff0", "0x2b3781d931c9efb09e301126e00c7313d83633af61768a199c335c419eaf1cbd"]],[["0x31c64b55694c35e496d922561ffed2f980fb6a5f8d6f19133ee301ed9ed3d5a",["0x1902d7bb38000", "0x40000","0x911dd67a26f008a36c26fba1291af64ca6f02d181c0f0a81f23ff86b1e7229d8", "0x97c8b70e65c8f19fd2734f0efd67b24e936ee58fca93a82229354590084e2680"]],[["0x65206031447b4ac653e56693e192691f48ef987833267ec32bd91af5c82b599", ["0x8acd72dcc600","0x30000","0xef8ce2413e801dcdda63964a50740f75ee79a1f2a18a3068bd8f2de7b6f36cc4","0xc2420a5be92ed2c1dada31c68e9b1a714c97e6a66722acccc9b25d933c54c32"]],<. ..>,"0x0","0x0"]
```

This list contains details of all current election candidates and more additional information about the current election. The first seen 4 items in the list have a separate value and contain:

* Beginning of validation cycle start time for current election candidates `0x5f2ac14f` (UNIX time, UTC, in seconds: 05.08.2020 14:25:19);
* End time of the current election round `0x5f2aa14f` (05.08.2020 12:08:47);
* Minimum needed steak for the current election `0x9184e72a000` (10000000000000 nanotokens = 10,000 tokens), that will be taken by the elector from the network configuration parameter #17;
* The current total steak amount of all currently submitted candidates that there are `0xdc4962e68d800` (3875324000000000 nanotokens = 3,875,324 tokens).

The last 2 shown items in the list also have a separate value and shows us:

* Status of failure of the current election process that we had `0x0` (0x0 - no failure, 0x1 - yes, can occur for various reasons, for example lack of needed candidates);
* Sucessful completion of the ongoing election process `0x0` (0x0 - election is still ongoing, 0x1 - election is over).

After the first seen 4 and up to the last 2 "individual" given values (after the first `%%[[%%` and before the last one `%%]]%%`) the validator list of given candidates for our current election, with more extended information compared to `participant_list`, is situated.
Let's take our first one candidate as an example:

* The given candidate validator public key `2a229b32309aa794bd89b5be44dd5eb8c50febd1f81251864856f911ca32eae` (we should mention that for "completeness" of process and for equal key length with other entries, it should have added `0` to the beginning; the most significant digits are omitted);
* the amount of needed tokens he specified as `0xf1041edd9000` (265000000000000 nanotokens = 265,000 tokens);
* max-factor that was specified by the candidate validator when applying for the election `0x30000` is written as 65536\*max-factor (0x30000/65536=3);
* The used address of the wallet from which the validator filing took place, recorded without specifying a workchain `0x315cf279d9503e0da1007aa3b08ed3dac3dc1b32ba9a1c0163dd4a0a8c82fff0` (-1:315cf279d9503e0da1007aa3b08ed3dac3dc1b32ba9a1c0163dd4a0a8c82fff0);
* ADNL address of the given validator node `0x2b3781d931c9efb09e301126e00c7313d83633af61768a199c335c419eaf1cbd`.

By the same shown way and by the same order, the list gives us specific details for all other candidates who have already been submitted their candidature for the current election.

```
Result: ["0x0","0x0","0x0","0x0",null,"0x0","0x0"]
```

The list will remain empty if there is no election for now (or if none of the candidates have yet applied for that election). It's more favorable to say that the list is not empty, it just contains one "zero" entry and it is used by the elector as an indicator for an empty list.

Implementation of the method can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1071

### compute\_returned\_stake

**Parameters of method**: the address of our wallet (without need of specifying current workchain, as an integer) from which the request has been submitted before to the validator in the past

**Returned data**: the number of given tokens (steak + part of the total reward) that the elector can return to a submitted wallet upon request (look at "message from steak return requests" below), shown in nanotokens

**Request sample**: `tonos-cli runget -1:3333333333333333333333333333333333333333333333333333333333333333 compute_returned_stake 0x315cf279d9503e0da1007aa3b08ed3dac3dc1b32ba9a1c0163dd4a0a8c82fff0`

**Result:**

```
Result: ["0xe9937fae1665"]
```

The elector is already ready to return to the purse specified in our given example (-1:315cf279d9503e0da1007aa3b08ed3dac3dc1b32ba9a1c0163dd4a0a8c82fff0) `0xe9937fae1665` (256819711579749 nanotokens, ≈ 256,819.71 tokens)

```
Result: ["0x0"]
```

If returned back with `0` - the elector has nothing to return to this wallet. Mostly possible reasons: it was not submitted before for the last election, or the freeze period still hasn't expired yet.

Implementation of the method can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1091

### past\_election\_ids

'*Method parameters**:** <none>*

**Returned data**: Identifications of past elections (maximum 2)

**Example call**: `tonos-cli runget -1:33333333333333333333333333333333333333333333333333333333 past_election_ids`

**Result**:

```
Result: [["0x5f28c14f",["0x5f29c14f",null]]]
```

List of shown identifiers of two (at most) past elections (the list here ends with null), by time from the oldest to newest: `5f28c14f` (in validation cycle has ended 04.08.2020 02:00:47) and `5f29c14f` (cycle ended 04.08.2020 20:13:03).

Implementation of the method can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1099

### past\_elections

'*Method parameters**:** <none>*

**Returned data**: the given details of the past\_elections: ID, time of defrosting (opening possibility to return back) of steaks, total given amount of steak, total collected reward and other data (see in example)

**Example call**: `tonos-cli runget -1:333333333333333333333333333333333333333333333333333333 past_elections`

**Result:**

```
Result: [[["0x5f28c14f","0x5f2a415a","0x8000","0x2801b2680a67daf019acdd3304028b529879fe7c26689912719980e0a5df0327",{"cell": null},"0x20390022b7e000","0x374434c1c013",null],[["0x5f29c14f","0x5f2b414f","0x8000","0x3945e68b703f88c3ea7106d9a2bd2b2c42d5b631acb60050fd7a0de5b9d4a6fb",{"cell": null},"0x210eb2f4792800","0x10bdbb297a8d",null],null]]]
```

List of data from last two (max) past elections (the list here ends with null), consider as the first item in the list:

1. election ID identifier `5f28c14f` (election already passed in validation cycle ending at 04.08.2020 02:00:47);
2. time till unfreeze (open return capability) the placed steaks for the validators selected in that current election `5f2a415a` (05.08.2020 05:19:22);
3. needed time period during after which the validation period the steak is not available for return no more (frozen) `0x8000` (32768, in seconds); the shown value of this parameter is taken by the elector from the current network configuration parameter #15;
4. validator set identifier `0x2801b2680a67daf019acdd3304028b5298798fe7c26689912719980e0a5df0327` (vset\_hash);
5. list of all validators penalized as a result of collected complaints `%%%{"cell":null}%%%` (the list is empty in our example);
6. total number of steak of all validators chosen in that election `0x20390022b7e000` (9069872000000000 nanotokens = 9,069,872 tokens);
7. the total reward that was collected by the elector for the validators who did win that election and ran their cycle; in our example `0x374434c1c013` (60766082416659 nanotokens ≈ 60,766.08 tokens)
8. list of collected complaints submitted to validators; in our example it's `null` - the list reamains empty.

By the same way (in the same order) values that are given for newer elections. Note: if you do call this method several times in a row, then in the last item in our list (which is the second in the given example) you can see how the total amount award of winning validators (who are working in this current cycle) "globally" continues to grow.

Implementation of the method can be found: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1112

### past\_elections\_list

'*Method parameters**:** <absent>*.

**Returned data**: information about past held elections: ID, defrost needed time for steaks; the list is very similar to the one returned by `past_elections`, but contains bit less data

**Example call**: `tonos-cli runget -1:333333333333333333333333333333333333333333333333333333 past_elections_list`

**Result:**

```
Result: [[["0x5f28c14f","0x5f2a415a","0x2801b2680a67daf019acdd3304028b529879fe7c26689912719980e0a5df0327","0x8000"], [["0x5f29c14f","0x5f2b414f","0x3945e68b703f88c3ea7106d9a2bd2b2c42d5b631acb60050fd7a0de5b9d4a6fb","0x8000"],null]]]
```

List of data from two (maximum) past elections (the list here ends with null), consider the first item in our list:

1. election ID identifier `5f28c14f` (election have passed in validation cycle ending at 04.08.2020 02:00:47);
2. time to unfreeze (open return capability) the given steaks for the validators selected in that passed election `5f2a415a` (05.08.2020 05:19:22);
3. validator set ID identifier `0x2801b2680a67daf019acdd3304028b5298798fe7c26689912719980e0a5df0327` (vset\_hash);
4. the period of needed time that the steak is no longer available for return (gets frozen) after the validation period `0x8000` (32768, in seconds); the value of current parameter is taken by the elector from the network configuration parameter #15.

Implementation of the method can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1125

### get\_past\_complaints

**Method parameters**: identifier of our passed elections

**Returned data**: the list of all complaints about the validators selected at the current elections, whose ID did pass as a method parameter

**Example call**: `tonos-cli runget -1:3333333333333333333333333333333333333333333333333333333333 get_past_complaints 0x5f28c14f`

**Result**:

```
Result: [null]
```

The list returned back in our example is empty (there are no complaints).

Method implementation can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1152

### show\_complaint

'*Parameters of the method*: identifier of the past elections and identifier of the complaint on the validator

**Returned data**: details about the specified complaint

**Example call**: `tonos-cli runget -1:33333333333333333333333333333333333333333333333333333333 show_complaint 0x5f28c14f <identifier_of_validator_complaint>`

Method implementation: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1162

### list\_complaints

**Method parameters**: identifier of past elections

**Returned data**: a list of all validator complaints selected at the election whose ID did pass as a method parameter; the method is very similar to `get_past_complaints`, but returns with more detailed data

**Example call**: `tonos-cli runget -1:3333333333333333333333333333333333333333333333333333333333333333 list_complaints 0x5f28c14a`

**Result:**

```
Result: [null]
```

The list returned in our example is empty (there are no complaints).

Method implementation can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1168

### complaint\_storage\_price

FIXME
**Method parameters**: number of shown bits in the complaint information, number of all references, expiry time of the complaint filed

**Returned data**: the needed price of filing and storing the complaint, shown in nanotokens

**Example call**: `tonos-cli runget -1:33333333333333333333333333333333333333333333333333333333333333333333 complaint_storage_price 32 1 3600`

**Result:**

```
Result: ["0x10408e6200"]
```

A complaint consists of 32 bits with 1 reference and stored for 3600 seconds (full one hour) requires `0x10408e6200` (69802549760 nanotokens ≈ 69.80 tokens).

Method implementation can be found here: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L1181

## Messages to the elector

The elector does receive and processes 2 main types of messages from validators during its current operation in the TON network:

* Sending steak (validator steak) for our election candidate for the next upcoming validation cycle;
* Returning the steak after it is in "freeze" period, which ends shortly soon after the next validation cycle.

Let us take a closer look at the contents of each of these messages that we got, and how to decode and retrieve useful for us information from them.

### Message - sending steak

Requests the elector to register as the candidate validator for our current election.

#### Message formation

The body of this current message is generated using the fift assembler using the validator-elect-req.fif and validator-elect-signed.fif command files.

The first to be used command file `validator-elect-req.fif` writes the following candidate validator information to the intermediate data content of our future message:

* The address of our wallet from which funds the whole steak is sent (the technical parameter for sending this message to the validator wallets smart contract, contains only in the message header, but not in the message body);
* Election ID identifier (UNIX timestamp of the UTC at the end of the validation cycle in which the election is being made) to which the candidate validator is submitted;
* Desired max-factor (can be seen bit later, in the description of the validator algorithm) of the candidate validator, which further does affect the election process;
* ADNL address of the candidate validators node.

All of the above shown information is written by default to another file, `validator-to-sign.bin`. This file further will be used only to generate an electronic signature (Ed25519) using the candidate validator's given public key; the finished signature is fed to the input of our next command file. The shown signature is generated by a candidate validator node because of that (and only that) program holds inside of the private key needed to sign the data from the `validator-to-sign.bin` file. Once the signature has been fully calculated, this intermediary file is no longer needed for our further work.

To form the final signed message for the elector the second command file `validator-elect-signed.fif` is now executed which forms the final message from the following data:

* The address ID of the wallet from whose funds the steak is currently sent (the technical parameter for sending this message to the validator wallet smart contract, contains only in the message header but not in messages body);
* Identifier ID of the election to which the candidate validator has been submitted;
* The desired max-factor value of the candidate validator;
* The ADNL address of the candidate validator node;
* The candidate validator's unique public key, which it will later on use to sign blocks in the validation process;
* Signature under the data that was generated by the first command file (the first 4 data chunks in our list);
* The request identifier to the elicitor (query\_id), by default this command file uses the current time stamp (UNIX time, UTC); used by the elicitor to make certain match requests and responses.

It means that the usable data is the same as in the first file, but now a correct signature has been generated under some of them by the first shown batch file and node and a public key that is attached by the elector to check our signature correctnes. The considered command file, while forming the messages body to the elector, also does check the received signature to ensure that the message is going to contain the correct signature computed using our specified candidate validator's public key. The completed BOC with the shown message is written by the default to the `validator-query.boc` file.

The total amount of tokens attached to the transaction of given message is equal to the desired steak amount with additional +1 token (1 token is returned back further in the reply message in case if the registration finished successfuly).

#### Decoding of the message

Of course, since all of the above data that is written in the body of the message - it is possible to extract and decode all of it from messages sent to the elector on behalf of the candidate validator given wallet. Let's look at this example of how it can be done without full BOC decoding, from wallet message data obtained using our beloved Free TON Blockchain Explorer:

1. Let's take our wallet with address -1:315cf279d9503e0da1007aa3b08ed3dac3dc1b32ba9a1c0163dd4a0a8c82fff0, namely it's section=details&id=2b272dae65f405474e04a8c0a974b9aaaf2888701f83fe4fc92533ad61bd8725;
2. Download the whole body of this message using the "Download" button next by it
3. Open it with any convenient HEX editor, for an example. HXD for Windows OS or Okteta for Linux OS.

The data of interest are at the specified hex offsets in the given message body:

* **D-10 (4 bytes)**: steak message marker `4E73744B`, highlighted in red colour;
* '**15-18 (4 bytes)**: [query\_id] elicitor request as identifier; is `5F287807` (message compiled 03.08.2020 20:48:07 UTC), highlighted in orange colour;
* **19-38 (32 bytes)**: candidate validator for public key; equal to `9EFC32527D4C95E8EBB124F5E92557EFB8EB2C9D1FD4ADCB6A53392DAF0A76A3`, highlighted in yellow colour;
* **39-3C (4 bytes)**: election identifier; equals to `5F28C14F` (election that was held in the cycle that ended 04.08.2020 02:00:47 UTC), highlighted in green colour;
* **3D-40 (4 bytes)**: candidate validator max-factor is written as 65536\*max-factor; equals to `00030000` (0x00030000/65536=3), highlighted in blue colour;
* **41-60 (32 bytes)**: the ADNL address ID of the candidate validator node; equals to `413DE28C11F2E1C1603E81865D40C0380F7C56AC9F91CAC862ECE721DECFC754`, highlighted in purple colour;
* signature was computed using the Ed25519 algorithm and the candidate validator's given public key.

### Message - steak return

Requests for the elector to return a previously frozen validator steak with a validation loop award added additionally.

#### Message generation

The body of our message is generated using the fift assembler using this command file recover-stake.fif.

The body of the message does contain only the query ID identifier for the elector (query\_id), which now is formed in the exact same way as a steak message. The finished message BOC is now written to the recover-query.boc file by default. There is no signature to show.

The amount of tokens that are attached to the transaction of our message equals to 1 token (to cover message transmission cost and all processing fees).

#### Decoding of message

As an example, we take message with ID identifier e8a2dbb3592dffdcf46c8f4c82139ae9cbf0bab091a5b232fb67a3b29ad2d5ef.
The data of our interest can be found at the specified hexadecimal offsets in our main message body:

* **D-10 (4 bytes)**: steak return message with marker `47657424`, highlighted in red colour;
* **15-18 (4 bytes)**: request ID identifier for our elector (query\_id); is `5F2877FB` (message is compiled at 03.08.2020 20:47:55 UTC), highlighted in orange colour.

## Messages from the elector

In response to the above given messages, the elector returns back with following messages:

* for a message with a steak amount for our candidate validator: a message with 1 token shows up as confirmation of successful registration or a message with the steak amount originally sent and an error code in case of failure to register our candidate;
* for the return steak message: returns with a message for the steak + full reward in case of success (validator was actually selected for this completed validation cycle, steak needed freeze time has passed and not more than 2 (two) cycles did pass after that or an recieved error message.

Let us take a more closer look at the given contents of each of these messages we got, as well as how to decode them and retrieve useful information out of it.

### message - response to steak message

It can contain both a successful message like (token F374484C) with 1 token, and an error message (with token EE6F454C) with the amount of tokens that were sent to the steak.

#### A successful message

As we consider the contents of the body of the successful message with 1 token and ID (identifier) 833dcfca104afa0e2a07b8f83753742a020f2005c643fb0bdfae67abdcbba10f:

* **D-10 (4 bytes)**: successful response as message marker `F374484C`, highlighted in red color;
* **15-18 (4 bytes)**: the request with identifier ID for the elector (query\_id) to which this response was sent before; is `5F287807`, highlighted in orange color.

#### An error message

FIXME Find such a message type in the mainnet, the current example is taken from the launched game network.

To consider the contents of the body of ourthe message with the candidate registration error and the returned steak amount, which has this identifier d8ba42b292f447ac588b6b66e2cba0bb5f9aaa62addd5c787d050aaee06f08aa:

* **D-10 (4 bytes)**: error response message with marker `EE6F454C`, highlighted in red color;
* **15-18 (4 bytes)**: the request identifier ID for the elector (query\_id) to which this response was sent before; is `5F2869F1`, highlighted in orange color;
* **19-1C (4 bytes)**: error code; equals to `00000001` (invalid signature), displayed in yellow color.

For the given fact that the response message contains an error code it does seems possible that to draw conclusions regarding its cause based on these calls to the return\_stake method in the elector code:

* code `00000000`: there currently is no election happening, or the wallet from which the steak was sent can not be found in the masterchain (-1);
* code `00000000` (same code): this election to which the steak was sent has already been completed;
* code `00000001`: the validator public key did not sign the message correctly (this may happen because the public key in the message field does not match the given one in signature);
* code `00000002`: submitted steak amount (after subtracting 1 token for confirmation) is less than 1/4096 (about ~0.02%) of the current total collected validator steak amount for our election;
* code `00000003`: the election ID does not match with the current election that is in progress (as an example it is taken from one of previous elections);
* code `00000004`: the steak is sent from a wallet that has already successfully sent it before for some other public validator key ID in the current election cycle;
* code `00000005`: the steak that is sent is less than the required minimum set in the network for configuration parameter #17;
* code `00000006`: the specified max-factor value is less than 1 (minimum needed value for this parameter);

### message - a response to message requesting the full return of a steak

It can contain both a successful message like (token F96F7324) with a validator steak + additional its part of the total given reward, and an error message like (token FFFFFFFFFE) without any tokens.

#### A successful message

To consider the contents of the body of the successful message that we got with the steak fully returned to the validator and its part of the total award being added to it. Sample message ID identificator e7bf0e3fbc770fdece696d32afad262e1f2559b510bf98dab7eb9c23f2d51f7a:

* **D-10 (4 bytes)**: successful response for message marker `F96F7324`, highlighted in red color;
* **15-18 (4 bytes)**: the request with ID identifier for the elector (query\_id) to which this response was sent before; is `5F2A4734`, highlighted in orange color.

#### Message with an error

Considering the contents of given error message body with no returned back steak and reward when only 1 recieved token (which was attached to our message requesting for the return) is returned back in response.
Sample message ID identificator 5f3e7bdd0a560cb716d2d7e152bb3c27af2529ca0d05b61963028452076b5ee7:

* **D-10 (4 bytes)**: error response message with marker `FFFFFFFFFE`, highlighted in red color;
* **15-18 (4 bytes)**: the request ID identifier of the elector (query\_id) to which this response was sent before; is `5F2A4734`, highlighted in orange color;
* **19-1C (4 bytes)**: the message (for operation) to return the steak back `47657424` (in this case it is how the send\_message\_back elector function is called, that it also gets back into the response message), highlighted in yellow color.

There are only 2 possible reasons for those non-returns of a steak with the award:

1. [File:Elector\_7|pngborder]]is not in the masterchain (-1) who did sent a request to elector to return steak and reward together;
2. elector does not owe anything to the elector being requesting the full steak and reward back to the given wallet; this can happen for many various reasons, for example:
	1. the wallet and it did not send the steak to the past election (did not participate in it at all);
	2. the wallet has already requested it and have received a steak with reward fully;
	3. it has been passed more than 2 cycles (elections) since the steak was fully unfrozen.

be:Elector
bg:Elector
cs:Elector
el:Elector
es:Elector
fr:Electeur
hi:Elector (निर्वाचक)
hu:Elector
hy:Elector
id:Elector
it:Elector
lv:Elector
ms:Elector
pt:Elector
ru:Elector
uk:Elector