runtime-calls.md

# Runtime calls

Calls are categorized according to the dispatch origin they require:

1. **User calls**: the dispatch origin for this kind of call must be signed by
the transactor. This is the only call category that can be submitted with an extrinsic.
1. **Root calls**: This kind of call requires a special origin that can only be invoked
through on-chain governance mechanisms.
1. **Inherent calls**: This kind of call is invoked by the author of the block itself
(usually automatically by the node).
1. **Disabled calls**: These calls can not be called directly, they are reserved for internal use by other runtime calls.


## User calls

There are **86** user calls from **21** pallets.

### Account - 1

#### unlink_identity - 0

<details><summary><code>unlink_identity()</code></summary>

Taking 0.0111 % of a block.

```rust
```
</details>


Unlink the identity associated with the account.

### Scheduler - 2

#### schedule - 0

<details><summary><code>schedule(when, maybe_periodic, priority, call)</code></summary>

Taking 0.0122 % of a block.

```rust
when: BlockNumberFor<T>
maybe_periodic: Option<schedule::Period<BlockNumberFor<T>>>
priority: schedule::Priority
call: Box<<T as Config>::RuntimeCall>
```
</details>


Anonymously schedule a task.

#### cancel - 1

<details><summary><code>cancel(when, index)</code></summary>

Taking 0.0236 % of a block.

```rust
when: BlockNumberFor<T>
index: u32
```
</details>


Cancel an anonymously scheduled task.

#### schedule_named - 2

<details><summary><code>schedule_named(id, when, maybe_periodic, priority, call)</code></summary>

Taking 0.0189 % of a block.

```rust
id: TaskName
when: BlockNumberFor<T>
maybe_periodic: Option<schedule::Period<BlockNumberFor<T>>>
priority: schedule::Priority
call: Box<<T as Config>::RuntimeCall>
```
</details>


Schedule a named task.

#### cancel_named - 3

<details><summary><code>cancel_named(id)</code></summary>

Taking 0.0248 % of a block.

```rust
id: TaskName
```
</details>


Cancel a named scheduled task.

#### schedule_after - 4

<details><summary><code>schedule_after(after, maybe_periodic, priority, call)</code></summary>

No weight available.

```rust
after: BlockNumberFor<T>
maybe_periodic: Option<schedule::Period<BlockNumberFor<T>>>
priority: schedule::Priority
call: Box<<T as Config>::RuntimeCall>
```
</details>


Anonymously schedule a task after a delay.

#### schedule_named_after - 5

<details><summary><code>schedule_named_after(id, after, maybe_periodic, priority, call)</code></summary>

No weight available.

```rust
id: TaskName
after: BlockNumberFor<T>
maybe_periodic: Option<schedule::Period<BlockNumberFor<T>>>
priority: schedule::Priority
call: Box<<T as Config>::RuntimeCall>
```
</details>


Schedule a named task after a delay.

#### set_retry - 6

<details><summary><code>set_retry(task, retries, period)</code></summary>

Taking 0.012 % of a block.

```rust
task: TaskAddress<BlockNumberFor<T>>
retries: u8
period: BlockNumberFor<T>
```
</details>


Set a retry configuration for a task so that, in case its scheduled run fails, it will
be retried after `period` blocks, for a total amount of `retries` retries or until it
succeeds.

Tasks which need to be scheduled for a retry are still subject to weight metering and
agenda space, same as a regular task. If a periodic task fails, it will be scheduled
normally while the task is retrying.

Tasks scheduled as a result of a retry for a periodic task are unnamed, non-periodic
clones of the original task. Their retry configuration will be derived from the
original task's configuration, but will have a lower value for `remaining` than the
original `total_retries`.

#### set_retry_named - 7

<details><summary><code>set_retry_named(id, retries, period)</code></summary>

Taking 0.0132 % of a block.

```rust
id: TaskName
retries: u8
period: BlockNumberFor<T>
```
</details>


Set a retry configuration for a named task so that, in case its scheduled run fails, it
will be retried after `period` blocks, for a total amount of `retries` retries or until
it succeeds.

Tasks which need to be scheduled for a retry are still subject to weight metering and
agenda space, same as a regular task. If a periodic task fails, it will be scheduled
normally while the task is retrying.

Tasks scheduled as a result of a retry for a periodic task are unnamed, non-periodic
clones of the original task. Their retry configuration will be derived from the
original task's configuration, but will have a lower value for `remaining` than the
original `total_retries`.

#### cancel_retry - 8

<details><summary><code>cancel_retry(task)</code></summary>

Taking 0.012 % of a block.

```rust
task: TaskAddress<BlockNumberFor<T>>
```
</details>


Removes the retry configuration of a task.