Octez

https://octez.tezos.com/docs/active/
Admin
Octez is the reference implementation of the Tezos blockchain protocol, providing a node...
Tokens:113,348
Snippets:708
Trust Score:10
Update:11 months ago
Show doc for...
Tokens:
Raw
### Octez Multisig M-of-N Example Output

Source: https://octez.tezos.com/docs/active/native_multisig

Example JSON output for setting up an M-of-N multisig account using the Octez CLI. It includes the multisig public key and hash, a proof, and a list of secret shares distributed among participants, each with an ID and secret key.

```json
{
  "public_key": "BLpk...",
  "public_key_hash": "tz4...",
  "proof": "BLsig...",
  "secret_shares":
    [
      { "id": 1, "secret_key": "BLsk..." },
      { "id": 2, "secret_key": "BLsk..." },
      { "id": 3, "secret_key": "BLsk..." },
      // ...
    ]
}
```

--------------------------------

### Octez Multisig N-of-N Example Output

Source: https://octez.tezos.com/docs/active/native_multisig

Example JSON output for setting up an N-of-N multisig account using Octez CLI or RPC. It shows the generated public key and the corresponding public key hash for the multisig address.

```json
{
  "public_key": "BLpk...",
  "public_key_hash": "tz4..."
}
```

--------------------------------

### DAL Publish Commitment RPCs - OCaml

Source: https://octez.tezos.com/docs/active/dal_support

This snippet demonstrates how to interact with the DAL node to create a commitment and retrieve its proof using OCaml. It shows example RPC calls for `POST /commitment` and `GET /commitments/<commitment>/proof`.

```ocaml
(* Example of creating a commitment using the DAL node *) 
let create_commitment data = 
  let json_data = Ezjsonm.from_string data in 
  Lwt_main.run @@ Http_client.post "/commitment" json_data

(* Example of retrieving a commitment's proof *) 
let get_commitment_proof commitment = 
  Lwt_main.run @@ Http_client.get (Printf.sprintf "/commitments/%s/proof" commitment)
```

--------------------------------

### Michelson Shortcut Rule Example

Source: https://octez.tezos.com/docs/active/michelson

Presents a simplified rule format used in Michelson specifications for program rewriting, demonstrating a shortcut for sequential execution.

```michelson
p / S  =>  p' / S'
```

--------------------------------

### Michelson Code Pattern Examples

Source: https://octez.tezos.com/docs/active/michelson

Illustrates the syntax for Michelson code patterns, including simple instructions, compound instructions with arguments, sequences of instructions, and pattern matching.

```michelson
DROP
PUSH nat 3
IF { SWAP ; DROP } { DROP }
```

--------------------------------

### Example Michelson Typing Derivation

Source: https://octez.tezos.com/docs/active/michelson

Illustrates a step-by-step typing derivation for a small Michelson program that computes (x+5)*10. This example shows how typing rules are instantiated and applied recursively to determine the type of a program.

```michelson
{ PUSH nat 5 ; ADD ; PUSH nat 10 ; MUL }
:: [ nat : [] -> nat : [] ]
   by { PUSH nat 5 ; ADD }
      :: [ nat : [] -> nat : [] ]
         by PUSH nat 5
            :: [ nat : [] -> nat : nat : [] ]
               by 5 :: nat
        and ADD
            :: [ nat : nat : [] -> nat : [] ]
  and { PUSH nat 10 ; MUL }
      :: [ nat : [] -> nat : [] ]
         by PUSH nat 10
            :: [ nat : [] -> nat : nat : [] ]
               by 10 :: nat
        and MUL
            :: [ nat : nat : [] -> nat : [] ]
```

--------------------------------

### Michelson Stack Pattern Examples

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates the syntax for Michelson stack patterns, covering the failed state, empty stack, destructured stacks, and named stack patterns.

```michelson
[FAILED]
[]
x : y : rest
```

--------------------------------

### Octez Client Mockup REPL Usage

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates the setup and basic usage of the interactive Michelson toplevel (REPL) provided by the Octez client in mockup mode. It shows how to initialize the mockup environment and interact with simple Michelson instructions like UNIT and COMPARE.

```Shell
$ octez-client --mode mockup --base-dir /tmp/mockup create mockup
$ rlwrap scripts/michelson_repl.sh
> UNIT
  { Stack_elt unit Unit }
> UNIT
  { Stack_elt unit Unit ; Stack_elt unit Unit }
> COMPARE
  { Stack_elt int 0 }


```

--------------------------------

### Unit Test: SWAP Instruction

Source: https://octez.tezos.com/docs/active/michelson

This example tests the effect of the `SWAP` instruction on a stack containing a `nat` and a `bool`. It shows how the order of elements is reversed after the `SWAP` operation.

```unknown
input
  {
    Stack_elt nat 8 ;
    Stack_elt bool False
  };
code SWAP;
output
  {
    Stack_elt bool False ;
    Stack_elt nat 8
  }
```

--------------------------------

### TZT Unit Test for SET_DELEGATE Operation

Source: https://octez.tezos.com/docs/active/michelson

Example unit test demonstrating the TZT syntax for the SET_DELEGATE instruction. It shows the expected input stack, the SET_DELEGATE code, and the resulting output stack, including a wildcard for the nonce.

```TZT
input { Stack_elt (option key_hash) (Some "tz1NwQ6hkenkn6aYYio8VnJvjtb4K1pfeU1Z") } ;
code SET_DELEGATE ;
output { Stack_elt operation (Set_delegate (Some "tz1NwQ6hkenkn6aYYio8VnJvjtb4K1pfeU1Z") _) }
```

--------------------------------

### Tezos Internal Operations Stack Execution (Depth-First)

Source: https://octez.tezos.com/docs/active/michelson

Provides a detailed step-by-step view of how internal operations are executed using a stack in a depth-first manner. This example shows the progression of operations and emissions during the execution of multiple external operations.

```text
+-----------+---------------+--------------------------+
| executing | emissions     | resulting stack          |
+-----------+---------------+--------------------------+
| op 1      | 1a, 1b, 1c    | 1a, 1b, 1c               |
| op 1a     | 1ai, 1aj      | 1ai, 1aj, 1b, 1c         |
| op 1ai    |               | 1aj, 1b, 1c              |
| op 1aj    |               | 1b, 1c                   |
| op 1b     | 1bi           | 1bi, 1c                  |
| op 1bi    |               | 1c                       |
| op 1c     |               |                          |
| op 2      | 2a, 2b        | 2a, 2b                   |
| op 2a     | 2ai           | 2ai, 2b                  |
| op 2ai    | 2ai1          | 2ai1, 2b                 |
| op 2ai1   |               | 2b                       |
| op 2b     | 2bi           | 2bi                      |
| op 2bi    | 2bi1          | 2bi1                     |
| op 2bi1   | 2bi2          | 2bi2                     |
| op 2bi2   |               |                          |
+-----------+---------------+--------------------------+

```

--------------------------------

### Michelson Data Pattern Examples

Source: https://octez.tezos.com/docs/active/michelson

Shows the syntax for Michelson data patterns, including literals for numbers, strings, bytes, symbolic constants, tagged data, and named patterns.

```michelson
3
"contents"
0xABCDEF42
Unit
True
False
(Pair 3 4)
```

--------------------------------

### Michelson Rule Syntax Example

Source: https://octez.tezos.com/docs/active/michelson

Illustrates the general form of rules used in the Michelson interpreter's big-step semantics. This includes syntax and stack patterns, conditions, and recursive calls for defining computations.

```plaintext
> (syntax pattern) / (initial stack pattern)  =>  (result stack pattern)
    iff (conditions)
    where (recursions)
    and (more recursions)
```

--------------------------------

### Unit Test: FAILWITH Instruction

Source: https://octez.tezos.com/docs/active/michelson

This example tests the `FAILWITH` instruction. It shows how to define an input stack and expect a specific error output when `FAILWITH` is executed.

```unknown
input {Stack_elt nat 2};
code FAILWITH;
output (Failed 2)
```

--------------------------------

### Empty Michelson Contract Example

Source: https://octez.tezos.com/docs/active/michelson

Presents the code for the simplest Michelson contract, where both the parameter and storage types are 'unit'. This contract demonstrates the basic structure including the CDR, NIL operation, and PAIR instructions to adhere to the calling convention.

```Michelson
code { CDR ;           # keep the storage
       NIL operation ; # return no internal operation
       PAIR };         # respect the calling convention
storage unit;
parameter unit;


```

--------------------------------

### Octez Sandbox Tutorial: Setting Up and Interacting with Sapling Contracts

Source: https://octez.tezos.com/docs/active/sapling

This script demonstrates the end-to-end testing of the Sapling system using the sandboxed mode in Octez. It covers setting up the sandbox, originating a Sapling contract, generating keys for Alice and Bob, performing shielding, shielded transfers, and unshielding operations.

```bash
# set up the sandbox
./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
octez-activate-alpha

# originate the contract with its initial empty sapling storage,
# bake a block to include it.
# { } represents an empty Sapling state.
octez-client originate contract shielded-tez transferring 0 from bootstrap1 \
running src/proto_023_PtSeouLo/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz \
--init '{ }' --burn-cap 3 &
octez-client bake for bootstrap1

# if necessary, you can get information from the octez-client manual
octez-client sapling man

# generate two shielded keys for Alice and Bob and use them for the shielded-tez contract
# the memo size has to be indicated
octez-client sapling gen key alice
octez-client sapling use key alice for contract shielded-tez --memo-size 8
octez-client sapling gen key bob
octez-client sapling use key bob for contract shielded-tez --memo-size 8

# generate an address for Alice to receive shielded tokens.
octez-client sapling gen address alice
zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Alice's address


# shield 10 tez from bootstrap1 to alice
octez-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
octez-client bake for bootstrap1
octez-client sapling get balance for alice in contract shielded-tez

# generate an address for Bob to receive shielded tokens.
octez-client sapling gen address bob
zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Bob's address

# forge a shielded transaction from alice to bob that is saved to a file
octez-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez

# submit the shielded transaction from any transparent account
octez-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
octez-client bake for bootstrap1
octez-client sapling get balance for bob in contract shielded-tez

# unshield from bob to any transparent account
octez-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
ctrl+z # to put the process in background
octez-client bake for bootstrap1
fg # to put resume the transfer

```

--------------------------------

### DAL Participation RPC Output Example

Source: https://octez.tezos.com/docs/active/dal_support

This JSON object represents the expected output from the `GET /chains/main/blocks/<block>/delegates/<pkh>/dal_participation` RPC endpoint. It provides insights into a delegate's DAL participation status within a cycle, including assigned shards, attested slots, expected rewards, and qualification for rewards.

```json
{
  "expected_assigned_shards_per_slot": 409,
  "delegate_attested_dal_slots": 2,
  "delegate_attestable_dal_slots": 5,
  "expected_dal_rewards": "1278125",
  "sufficient_dal_participation": false,
  "denounced": false
}
```

--------------------------------

### Micheline JSON Encoding Examples

Source: https://octez.tezos.com/docs/active/michelson

Provides examples of how different Micheline expression types, such as integers, strings, sequences, and primitive applications, are represented in JSON format. It shows the structure for encoding these elements.

```JSON
{ "int": "N" }

```

```JSON
{ "string": "contents" }

```

```JSON
[ expr, ... ]

```

```JSON
{ "prim": "pair", "args": [ { "prim": "nat", "args": [] }, { "prim": "nat", "args": [] } ], "annots": [":t"] }

```

--------------------------------

### Browse octez-client commands and manual

Source: https://octez.tezos.com/docs/active/cli-commands

These commands allow users to browse the available commands and the full manual of the octez-client. 'man' lists commands, and 'man -v 3' provides the complete documentation.

```shell
octez-client [global options] man

```

```shell
octez-client [global options] man -v 3

```

--------------------------------

### Access octez-client help and version

Source: https://octez.tezos.com/docs/active/cli-commands

These commands provide quick access to help information for the octez-client. '--help' displays global options and command-specific options, while '--version' shows the client's version.

```shell
octez-client --help

```

```shell
octez-client [global options] command --help

```

```shell
octez-client --version

```

--------------------------------

### Execute Epoxy Origination with Octez Client

Source: https://octez.tezos.com/docs/active/cli-commands

This command initiates an Epoxy origination operation. It requires specifying the source contract ('src'), rollup details ('rollup'), and operation details ('ops'). Various optional flags allow for granular control over fees, gas limits, storage limits, dry runs, simulations, and more.

```bash
octez-client epoxy publish from <src> rollup <rollup> ops <ops> [--default-fee <amount>] [-D --dry-run] [--verbose-signing] [--simulation] [-G --default-gas-limit <amount>] [--safety-guard <extra_gas>] [-S --default-storage-limit <amount>] [-C --counter <counter>] [--default-arg <data>] [-q --no-print-source] [--minimal-fees <amount>] [--minimal-nanotez-per-byte <amount>] [--minimal-nanotez-per-gas-unit <amount>] [--force-low-fee] [--fee-cap <amount>] [--burn-cap <amount>] [--default-entrypoint <name>] [--replace]
```

--------------------------------

### Registering a Global Constant in Octez (Micheline Example)

Source: https://octez.tezos.com/docs/active/global_constants

This snippet demonstrates registering a Micheline code fragment as a global constant using the 'register_global_constant' operation. The example shows registering an integer and a lambda expression. The output includes the hash of the registered expression, which can then be used to reference the constant.

```text
Operation: register_global_constant
Expression: 999
Receipt Hash: expruQN5r2umbZVHy6WynYM8f71F8zS4AERz9bugF8UkPBEqrHLuU8

Expression: { PUSH int 999; ADD }
Receipt Hash: (hash of the lambda expression)
```

--------------------------------

### Get Delegate Baking Power

Source: https://octez.tezos.com/docs/active/baking_power

Retrieves the current baking power of a specific delegate as of the end of a given block.

```APIDOC
## GET /delegates/{delegate_pkh}/baking_power

### Description
This RPC endpoint retrieves the current baking power of a delegate for a specified block.

### Method
GET

### Endpoint
`/chain/<chain_id>/blocks/<block_id>/context/delegates/<delegate_pkh>/baking_power`

### Parameters
#### Path Parameters
- **delegate_pkh** (string) - Required - The public key hash of the delegate.
- **chain_id** (string) - Required - The ID of the chain.
- **block_id** (string) - Required - The identifier of the block.

### Request Example
(No request body for this GET request)

### Response
#### Success Response (200)
- **baking_power** (integer) - The calculated baking power of the delegate.

#### Response Example
```json
{
  "baking_power": 123456789
}
```
```

--------------------------------

### GET /chains/main/blocks/<block>/delegates/<pkh>/dal_participation

Source: https://octez.tezos.com/docs/active/dal_support

Retrieves the DAL participation information for a specific baker (delegate) at a given block level.

```APIDOC
## GET /chains/main/blocks/<block>/delegates/<pkh>/dal_participation

### Description
This RPC endpoint provides detailed DAL participation metrics for a given baker (identified by `<pkh>`) within the context of a specific block (`<block>`). It includes information on assigned shards, attested slots, attestable slots, expected rewards, and participation status relative to the reward threshold.

### Method
GET

### Endpoint
`/chains/main/blocks/<block>/delegates/<pkh>/dal_participation`

### Parameters
#### Path Parameters
- **block** (string) - Required - The hash or level of the block to query.
- **pkh** (string) - Required - The public key hash (address) of the delegate.

#### Query Parameters
None

#### Request Body
None

### Request Example
```json
GET /chains/main/blocks/BLk123abc/delegates/tz1abc...xyz/dal_participation
```

### Response
#### Success Response (200)
- **expected_assigned_shards_per_slot** (integer) - The number of shards assigned to this baker per slot in the current cycle.
- **delegate_attested_dal_slots** (integer) - The number of DAL slots the baker has attested so far.
- **delegate_attestable_dal_slots** (integer) - The number of DAL slots that are attestable by the baker.
- **expected_dal_rewards** (string) - The expected rewards (in mutez) the delegate will receive if it meets the participation threshold and is not denounced.
- **sufficient_dal_participation** (boolean) - A flag indicating if the delegate's current attestation rate meets the minimum threshold (64%) to qualify for rewards.
- **denounced** (boolean) - A flag indicating if the delegate has been denounced in the current cycle.

#### Response Example
```json
{
  "expected_assigned_shards_per_slot": 409,
  "delegate_attested_dal_slots": 2,
  "delegate_attestable_dal_slots": 5,
  "expected_dal_rewards": "1278125",
  "sufficient_dal_participation": false,
  "denounced": false
}
```
```

--------------------------------

### Setting up M-of-N Multisig Account (Threshold Signature)

Source: https://octez.tezos.com/docs/active/native_multisig

This section covers the Octez client command for setting up an M-of-N multisig account, where a threshold number of participants must sign an operation.

```APIDOC
## M-of-N (Threshold Signature) Setup

### Description
Sets up an M-of-N multisig account using Shamir's Secret Sharing algorithm. A threshold number (M) of participants out of N must sign an operation for it to be valid.

### Client Command
```bash
octez-client share bls secret key <sk> between <N> shares with threshold <M>
```

#### Parameters
- `sk` (string) - Required - The unencrypted secret key of the multisig account.
- `N` (integer) - Required - The total number of participants.
- `M` (integer) - Required - The threshold number of signatures required.

### Request Example (Client Command)
```bash
octez-client share bls secret key BLsk... between 3 shares with threshold 2
```

### Response Example (Client Command)
```json
{
  "public_key": "BLpk...",
  "public_key_hash": "tz4...",
  "proof": "BLsig...",
  "secret_shares": [
    {
      "id": 1,
      "secret_key": "BLsk..."
    },
    {
      "id": 2,
      "secret_key": "BLsk..."
    },
    {
      "id": 3,
      "secret_key": "BLsk..."
    }
    // ... more shares
  ]
}
```

**Note:** There is no associated RPC endpoint for this operation as it would require sending a secret key.
```

--------------------------------

### Setting up N-of-N Multisig Account (Signature Aggregation)

Source: https://octez.tezos.com/docs/active/native_multisig

This section details the Octez client command and RPC endpoint for setting up an N-of-N multisig account, where all participants must sign an operation.

```APIDOC
## N-of-N (Signature Aggregation) Setup

### Description
Sets up an N-of-N multisig account by aggregating the public keys of participants. All N members must sign every operation for it to be valid.

### Client Command
```bash
octez-client aggregate bls public keys '[{"public_key":"<pk_1>","proof":"<proof_1>"}, ..., {"public_key":"<pk_N>","proof":"<proof_N>"}]'
```

### RPC Endpoint
`/bls/aggregate_public_keys`

```bash
POST /bls/aggregate_public_keys
```

#### Parameters
**Client Command Parameters**
- `public_keys` (array of objects) - Required - An array of participant public keys and their proofs-of-possession.
  - `public_key` (string) - Required - The public key of a participant.
  - `proof` (string) - Required - The proof-of-possession for the participant's public key.

**RPC Request Body**
```json
{
  "public_keys": [
    {
      "public_key": "<pk_1>",
      "proof": "<proof_1>"
    },
    // ... more participants
    {
      "public_key": "<pk_N>",
      "proof": "<proof_N>"
    }
  ]
}
```

### Request Example (Client Command)
```bash
octez-client aggregate bls public keys '[{"public_key":"BLpk...","proof":"BLsig..."}]'
```

### Response Example (Client Command & RPC)
```json
{
  "public_key": "BLpk...",
  "public_key_hash": "tz4..."
}
```

### Creating Proof-of-Possession (PoP)
To create a proof-of-possession for a public key:

```bash
octez-client create bls proof for <pk_i>
```
```

--------------------------------

### RPC Errors

Source: https://octez.tezos.com/docs/active/plugins

Documentation detailing the possible errors returned by the Octez RPC interface. This guide helps in understanding and handling error responses.

```APIDOC
## RPC Errors

### Description
This section details the various error codes and messages that can be returned by the Octez RPC interface. Understanding these errors is crucial for effective debugging and error handling in client applications.

### Error Structure
RPC errors typically follow a structured JSON format:

```json
{
  "kind": "string",
  "id": "string",
  "errors": [
    {
      "kind": "string",
      "id": "string",
      "msg": "string"
    }
  ]
}
```

### Common Error Kinds
- **`branch`**: Errors related to the blockchain context or history.
- **`validation`**: Errors occurring during the validation of operations or blocks.
- **`michelson`**: Errors related to the execution of Michelson smart contracts.
- **`internal`**: Internal server errors within the Octez node.

### Example Error Response
```json
{
  "kind": "validation",
  "id": "Invalid_operation",
  "errors": [
    {
      "kind": "temporary",
      "id": "BLOCKED_OPERATION",
      "msg": "Operation is considered invalid by the current protocol."
    }
  ]
}
```
```

--------------------------------

### Michelson Empty Annotation Usage

Source: https://octez.tezos.com/docs/active/michelson

Shows how an empty annotation can be used as a wildcard to ignore specific field constraints or annotations, for example, with PAIR or UNPAIR.

```michelson
PAIR % %right
UNPPAIPAIR %x1 % %x3 %x4
```

--------------------------------

### Michelson Annotation Ordering Example

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates that the order of different annotation kinds (variable, type, field) does not matter, but the order within the same kind is significant.

```michelson
PAIR :t @my_pair %x %y

PAIR %x %y :t @my_pair
```

--------------------------------

### Michelson CONTRACT Instruction Variants

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates the behavior of the CONTRACT instruction with and without specific entrypoints, showing how it resolves contract addresses and their associated types. It highlights the equivalence of default entrypoints and the handling of unknown entrypoints.

```Michelson
+---------------+---------------------+------------------------------------------+
| input address | instruction         | output contract                          |
+---------------+---------------------+------------------------------------------+
| "addr"        | CONTRACT t          | (Some "addr") if contract exists, has a  |
|               |                     | default entrypoint of type t, or has no  |
|               |                     | default entrypoint and parameter type t  |
+---------------+---------------------+------------------------------------------+
| "addr%name"   | CONTRACT t          | (Some "addr%name") if addr exists and    |
+---------------+---------------------+ has an entrypoint %name of type t        |
| "addr"        | CONTRACT %name t    |                                          |
+---------------+---------------------+------------------------------------------+
| "addr%_"      | CONTRACT %_ t       | None                                     |
+---------------+---------------------+------------------------------------------+


```

--------------------------------

### Unit Test: Custom NOW Timestamp

Source: https://octez.tezos.com/docs/active/michelson

This example demonstrates how to use the optional `now` primitive to specify a custom timestamp for the `NOW` instruction. It asserts that the `NOW` instruction returns the chosen timestamp.

```unknown
input {};
now "2020-01-08T07:13:51Z";
code NOW;
output { Stack_elt timestamp "2020-01-08T07:13:51Z" }
```

--------------------------------

### Alpha RPCs - Reference

Source: https://octez.tezos.com/docs/active/proof_of_stake

Reference documentation for the Alpha Protocol's RPC interface.

```APIDOC
## Alpha RPCs - Reference

### Description
This section provides a reference for the RPCs specific to the Alpha Protocol (development version) in Tezos.

### Method
GET, POST, PUT, DELETE (Varies by endpoint)

### Endpoint
/path/to/alpha/rpc/endpoint

### Parameters
(Details depend on specific RPCs)

### Request Example
```json
{
  "example": "request body for an Alpha RPC"
}
```

### Response
#### Success Response (200)
- **data** (any) - The response data from the RPC call.

#### Response Example
```json
{
  "example": "response body from an Alpha RPC"
}
```
```

--------------------------------

### Basic Unit Test: Empty Input, Code, and Output

Source: https://octez.tezos.com/docs/active/michelson

This snippet demonstrates the most basic unit test structure, asserting that executing no instructions on an empty stack successfully returns an empty stack. It uses the mandatory `input`, `code`, and `output` primitives.

```unknown
input {};
code {};
output {}
```

--------------------------------

### Michelson Context-Dependent Instruction Annotations

Source: https://octez.tezos.com/docs/active/michelson

Provides examples of automatic annotation inference for context-dependent instructions in Michelson. These rules help track stack information for bare contracts.

```michelson
ADDRESS  :: @c contract _ : 'S   ->   @c.address address : 'S

CONTRACT 'p  :: @a address : 'S   ->   @a.contract contract 'p : 'S

BALANCE :: 'S   ->   @balance mutez : 'S

SOURCE  :: 'S   ->   @source address : 'S

SENDER  :: 'S   ->   @sender address : 'S

SELF  :: 'S   ->   @self contract 'p : 'S

SELF_ADDRESS  :: 'S   ->   @self address : 'S

AMOUNT  :: 'S   ->   @amount mutez : 'S

NOW  :: 'S   ->   @now timestamp : 'S

LEVEL :: 'S  ->   @level nat : 'S
```

--------------------------------

### Alpha RPCs - Reference

Source: https://octez.tezos.com/docs/active/dal_support

Documentation for the experimental RPC endpoints in the Alpha development protocol. Includes specifications for new features and functionalities under development.

```APIDOC
## ALPHA RPC ENDPOINTS

### Description
Describes the RPC endpoints for the Alpha development protocol, which may include experimental features.

### Endpoints
[Detailed list of Alpha RPC endpoints will be described here, including:]

- **/chains/<chain_id>/blocks/<block_id>/header**
- **/chains/<chain_id>/blocks/<block_id>/operations**
- **/chains/<chain_id>/blocks/<block_id>/context/constants**

### Example
Request and response examples for each Alpha RPC endpoint would be specified.

```

--------------------------------

### Alpha RPCs - Reference

Source: https://octez.tezos.com/docs/active/index

Reference documentation for the Alpha Protocol's RPC interface.

```APIDOC
## Alpha RPCs - Reference

### Description
This section provides detailed reference documentation for the Alpha Protocol's RPC endpoints.

### Method
N/A (Reference documentation)

### Endpoint
N/A (Reference documentation)

### Parameters
N/A (Reference documentation)

### Request Example
N/A (Reference documentation)

### Response
N/A (Reference documentation)

#### Success Response (200)
N/A (Reference documentation)

#### Response Example
N/A (Reference documentation)
```

--------------------------------

### Michelson Nested PAIR Annotations

Source: https://octez.tezos.com/docs/active/michelson

Provides examples of macros for nested PAIRs that accept multiple annotations. Field annotations assign names to leaves of the constructed nested pair.

```michelson
PAPPAIIR @p %x1 %x2 %x3 %x4
:: 'a : 'b : 'c : 'd : 'S
   -> @p (pair ('a %x1) (pair (pair ('b %x) ('c %x3)) ('d %x4))) : 'S

PAPAIR @p %x1 %x2 %x3
:: 'a : 'b : 'c : 'S  ->  @p (pair ('a %x1) (pair ('b %x) ('c %x3))) : 'S
```

--------------------------------

### Shell RPCs - Reference

Source: https://octez.tezos.com/docs/active/timelock

Reference documentation for the Octez Shell RPCs, detailing available endpoints and their usage.

```APIDOC
## Octez Shell RPCs - Reference

### Description
Reference documentation for the Octez Shell RPCs, detailing available endpoints and their usage.

### Method
Not applicable (This section describes available RPCs, not a specific HTTP method).

### Endpoint
Not applicable (This section describes available RPCs, not a specific endpoint).

### Parameters
Not applicable (This section describes available RPCs, not specific parameters).

### Request Example
Not applicable.

### Response
Not applicable.
```

--------------------------------

### Michelson CDAR Annotation Inference Example

Source: https://octez.tezos.com/docs/active/michelson

Shows how the Tezos typechecker infers annotations for unannotated accesses like CAR and CDR. When fields are named, the inferred annotation is appended with '.field_name'.

```michelson
CDAR
:: @p (pair ('a %foo) (pair %bar ('b %x) ('c %y))) : 'S ->  @p.bar.x 'b : 'S
```

--------------------------------

### Michelson Recursive Rule Example

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates the structure of recursive rules within Michelson's big-step semantics. These rules define computations based on the results of interpreting intermediate program states.

```plaintext
where (intermediate program) / (intermediate stack)  =>  (partial result)
```

--------------------------------

### Set Delegate Staking Parameters (Convenience Command - octez-client)

Source: https://octez.tezos.com/docs/active/staking

A more user-friendly command to set delegate staking parameters. It takes the limit and edge values directly, abstracting the unit conversion required by the lower-level command.

```bash
octez-client set delegate parameters for <delegate> --limit-of-staking-over-baking <value> --edge-of-baking-over-staking <value>
```

--------------------------------

### Shell RPCs - Reference

Source: https://octez.tezos.com/docs/active/proof_of_stake

Reference documentation for the Octez Shell Remote Procedure Call (RPC) interface.

```APIDOC
## Shell RPCs - Reference

### Description
This section provides a reference for the Octez Shell RPCs, which allow interaction with the Octez node.

### Method
GET, POST, PUT, DELETE (Varies by endpoint)

### Endpoint
/path/to/rpc/endpoint

### Parameters
(Details depend on specific RPCs, typically no path or query parameters for general reference, but body parameters for POST/PUT)

### Request Example
```json
{
  "example": "request body for a specific RPC"
}
```

### Response
#### Success Response (200)
- **data** (any) - The response data from the RPC call.

#### Response Example
```json
{
  "example": "response body from a specific RPC"
}
```
```

--------------------------------

### Michelson Push-like Instructions with Type Annotations

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates how push-like instructions (constructors) in Michelson can be annotated with types. These annotations affect the resulting type on the stack, providing semantic information.

```michelson
UNIT :t
:: 'A -> (unit :t) : 'A

PAIR :t
:: 'a : 'b : 'S -> (pair :t 'a 'b) : 'S

SOME :t
:: 'a : 'S -> (option :t 'a) : 'S

NONE :t 'a
:: 'S -> (option :t 'a) : 'S

LEFT :t 'b
:: 'a : 'S -> (or :t 'a 'b) : 'S

RIGHT :t 'a
:: 'b : 'S -> (or :t 'a 'b) : 'S

NIL :t 'a
:: 'S -> (list :t 'a) : 'S

EMPTY_SET :t 'elt
:: 'S -> (set :t 'elt) : 'S

EMPTY_MAP :t 'key 'val
:: 'S -> (map :t 'key 'val) : 'S

EMPTY_BIG_MAP :t 'key 'val
:: 'S -> (big_map :t 'key 'val) : 'S
```

--------------------------------

### Tezos Baking Rewards and Bonus Distribution

Source: https://octez.tezos.com/docs/active/token_management

Shows balance updates after block operations are applied, distributing collected baking fees and rewards. Includes examples of frozen and spendable amounts for delegates and stakers.

```json
[ {"kind": "accumulator", "category": "block fees", "change": "-1000", ...},
  {"kind": "contract", "contract": "tz1a...", "change": "1000", ...}
  {"kind": "minted", "category": "baking rewards", "change": "-5", ...},
  {"kind": "freezer", "category": "deposits", "staker": { "baker_edge": "tz1a..."}, "change": "5", ...},
  {"kind": "minted", "category": "baking rewards", "change": "-10", ...},
  {"kind": "freezer", "category": "deposits", "staker": { "baker_own_stake": "tz1a..."}, "change": "10", ...},
  {"kind": "minted", "category": "baking rewards", "change": "-35", ...},
  {"kind": "freezer", "category": "deposits", "staker": { "delegate": "tz1a..."}, "change": "35", ...},
  {"kind": "minted", "category": "baking rewards", "change": "-450", ...},
  {"kind": "contract", "contract": "tz1a...", "change": "450", ...} ]

```

--------------------------------

### Michelson CDAR Annotation Inference with Named Fields Only

Source: https://octez.tezos.com/docs/active/michelson

Illustrates annotation inference for CDAR when the original pair is unnamed, but a field annotation exists. The accessed value gets a variable annotation from the field annotation.

```michelson
CDAR
:: (pair ('a %foo) (pair %bar ('b %x) ('c %y))) : 'S ->  @bar.x 'b : 'S
```

--------------------------------

### Alpha RPCs - Reference

Source: https://octez.tezos.com/docs/active/protocol

Reference documentation for the RPCs related to the Alpha protocol in Tezos.

```APIDOC
## Alpha RPCs - Reference

### Description
Details the Remote Procedure Calls (RPCs) specific to the Alpha protocol implementation within Tezos.

### Method
GET, POST, PUT, DELETE (and others as applicable)

### Endpoint
`/path/to/alpha/rpc/endpoint` (example)

### Parameters

#### Path Parameters
- **param_name** (type) - Required/Optional - Description of the path parameter.

#### Query Parameters
- **param_name** (type) - Required/Optional - Description of the query parameter.

#### Request Body
- **field_name** (type) - Required/Optional - Description of the request body field.

### Request Example
```json
{
  "example": "request body"
}
```

### Response
#### Success Response (200)
- **field_name** (type) - Description of the success response field.

#### Response Example
```json
{
  "example": "response body"
}
```
```

--------------------------------

### Seoul RPCs - Reference

Source: https://octez.tezos.com/docs/active/proof_of_stake

Reference documentation for the Seoul Protocol's RPC interface.

```APIDOC
## Seoul RPCs - Reference

### Description
This section provides a reference for the RPCs specific to the Seoul Protocol in Tezos.

### Method
GET, POST, PUT, DELETE (Varies by endpoint)

### Endpoint
/path/to/seoul/rpc/endpoint

### Parameters
(Details depend on specific RPCs)

### Request Example
```json
{
  "example": "request body for a Seoul RPC"
}
```

### Response
#### Success Response (200)
- **data** (any) - The response data from the RPC call.

#### Response Example
```json
{
  "example": "response body from a Seoul RPC"
}
```
```

--------------------------------

### Michelson Testing Static Type Checking Failure with DUP

Source: https://octez.tezos.com/docs/active/michelson

Demonstrates testing for static type checking failures in Michelson. This example asserts that the `DUP` instruction cannot be used on an empty stack, resulting in a `StaticError` which is broadly specified using a wildcard.

```michelson
input {};
code DUP;
output (StaticError _)

```

--------------------------------

### Michelson Testing Runtime Failure with FAILWITH

Source: https://octez.tezos.com/docs/active/michelson

Shows how to test for runtime failures in Michelson using the `output (Failed <value>)` syntax. This example asserts that the `FAILWITH` instruction produces a runtime error containing the top of the stack, which is the integer `4` in this case.

```michelson
input { Stack_elt nat 4 ; Stack_elt bytes 0x };
code FAILWITH;
output (Failed 4)

```

--------------------------------

### Alpha RPCs - Reference

Source: https://octez.tezos.com/docs/active/event

Reference documentation for the RPCs related to the Alpha protocol in Tezos.

```APIDOC
## Alpha RPCs - Reference

### Description
This section provides a reference for the RPCs specific to the Alpha protocol, detailing interactions with the economic protocol features.

### Method
GET, POST, PUT, DELETE (depending on the specific RPC)

### Endpoint
/path/to/alpha/rpc (specific endpoints vary)

### Parameters
(Varies per RPC. Detailed documentation is available in the full Octez documentation.)

### Request Example
(Varies per RPC. Refer to the specific RPC documentation.)

### Response
#### Success Response (200)
(Varies per RPC. Refer to the specific RPC documentation.)

#### Response Example
(Varies per RPC. Refer to the specific RPC documentation.)
```
Tokens:
Raw