# L2 Rollers

Here we outline how the naive rollup rollers work. This page is only a quick summary - the full documentation of the API is coming soon.

## Overview <a href="#overview" id="overview"></a>

The following diagram illustrates the most important parts of the plumbing present in the roller.

![](https://media.urbit.org/docs/layer2/roller-internal.png)

We elaborate on the components of this diagram below.

## `%roller-rpc` <a href="#roller-rpc" id="roller-rpc"></a>

The roller communicates with the outside world via a JSON-RPC API, which is implemented with a Gall agent `%roller-rpc`. This is how Bridge communicates with a roller. See the [RPC documentation](https://documenter.getpostman.com/view/16338962/Tzm3nx7x#5a698656-8e7e-433f-9eff-1c6047b9eace) for detailed information on the API.

## `%roller` <a href="#roller" id="roller"></a>

`%roller` is the Gall agent which collects layer 2 Azimuth **transactions**, which are a concatenation of an [action](/urbit-id/l2/bytestring.md#actions) and a [signature](/urbit-id/l2/bytestring.md#signatures) and forms them into [batches](/urbit-id/l2/bytestring.md#batch) to be submitted periodically to the Ethereum blockchain.

### Transaction format <a href="#transaction-format" id="transaction-format"></a>

See [Bytestring Format](/urbit-id/l2/bytestring.md) for a technical description of how layer 2 transactions are formatted.

### Pending transactions <a href="#pending-transactions" id="pending-transactions"></a>

`%roller` maintains in its state a list of transactions that have been submitted to it since the most recent roll it submitted to Ethereum. These are referred to as **pending transactions**.

### Signing the batch <a href="#signing-the-batch" id="signing-the-batch"></a>

Each pending transaction already includes a signature from its sender, but the roller itself must also sign the entire batch of transactions with its private key to submit it as a single Ethereum transaction. This signed batch is known as a **roll**.

### Predicted state <a href="#predicted-state" id="predicted-state"></a>

Once a roll has been submitted to an Ethereum node, there is a waiting period before a miner includes it in a block.

During this waiting period, the roller applies the submitted batch to the locally held Azimuth state to get a predicted state. This predicted state is presented to the user in Bridge, such as to show which points a given address owns.

### Timer <a href="#timer" id="timer"></a>

Each roller may choose to submit rolls on a regular basis, periodically and/or whenever a certain number of pending transactions is reached.


---

# 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://docs.urbit.org/urbit-id/l2/roller.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.
