# Protocol

### Genesis Config[​](https://docs.near.org/api/rpc/protocol#genesis-config) <a href="#genesis-config" id="genesis-config"></a>

> Returns current genesis configuration.

* method: `EXPERIMENTAL_abogida_config`
* params: *none*

Example:

{% tabs %}
{% tab title="JSON" %}

```
{
  "jsonrpc": "2.0",
  "id": "dontcare",
  "method": "EXPERIMENTAL_abogida_config"
}
```

{% endtab %}
{% endtabs %}

**What could go wrong?**[**​**](https://docs.near.org/api/rpc/protocol#what-could-go-wrong)

When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow verror convention for structuring the error response:

```
{
    "error": {
        "name": <ERROR_TYPE>,
        "cause": {
            "info": {..},
            "name": <ERROR_CAUSE>
        },
        "code": -32000,
        "data": String,
        "message": "Server error",
    },
    "id": "dontcare",
    "jsonrpc": "2.0"
}
```

> **Heads up**
>
> The fields `code`, `data`, and `message` in the structure above are considered legacy ones and might be deprecated in the future. Please, don't rely on them.

Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_abogida_config` method:

| <p>ERROR\_TYPE<br><code>error.name</code></p> | <p>ERROR\_CAUSE<br><code>error.cause.name</code></p> | Reason                                                  | Solution                                                                                                                                  |
| --------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| INTERNAL\_ERROR                               | INTERNAL\_ERROR                                      | Something went wrong with the node itself or overloaded | <ul><li>Try again later</li><li>Send a request to a different node</li><li>Check <code>error.cause.info</code> for more details</li></ul> |

### Protocol Config[​](https://docs.near.org/api/rpc/protocol#protocol-config) <a href="#protocol-config" id="protocol-config"></a>

> Returns most recent protocol configuration or a specific queried block. Useful for finding current storage and transaction costs.

* method: `EXPERIMENTAL_protocol_config`
* params:
  * `finality` *OR* `block_id`

Example:

* JSON
* HTTPie

```
{
  "jsonrpc": "2.0",
  "id": "dontcare",
  "method": "EXPERIMENTAL_protocol_config",
  "params": {
    "finality": "final"
  }
}
```

**What could go wrong?**[**​**](https://docs.near.org/api/rpc/protocol#what-could-go-wrong-1)

When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow verror convention for structuring the error response:

```
{
    "error": {
        "name": <ERROR_TYPE>,
        "cause": {
            "info": {..},
            "name": <ERROR_CAUSE>
        },
        "code": -32000,
        "data": String,
        "message": "Server error",
    },
    "id": "dontcare",
    "jsonrpc": "2.0"
}
```

> **Heads up**
>
> The fields `code`, `data`, and `message` in the structure above are considered legacy ones and might be deprecated in the future. Please, don't rely on them.

Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_protocol_config` method:

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td>ERROR_TYPE<br><code>error.name</code></td><td>ERROR_CAUSE<br><code>error.cause.name</code></td><td>Reason</td><td>Solution</td></tr><tr><td>HANDLER_ERROR</td><td>UNKNOWN_BLOCK</td><td>The requested block has not been produced yet or it has been garbage-collected (cleaned up to save space on the RPC node)</td><td><ul><li>Check that the requested block is legit</li><li>If the block had been produced more than 5 epochs ago, try to send your request to an archival node</li></ul></td></tr><tr><td>INTERNAL_ERROR</td><td>INTERNAL_ERROR</td><td>Something went wrong with the node itself or overloaded</td><td><ul><li>Try again later</li><li>Send a request to a different node</li><li>Check <code>error.cause.info</code> for more details</li></ul></td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://medeber-engineers.gitbook.io/https-www.abogida.network/tutorials/rpc-providers/protocol.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.