> For the complete documentation index, see [llms.txt](https://docs.ozelprotocol.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ozelprotocol.xyz/akash/deployments.md).

# Deployments

## General framework

Three `nodejs` files connected to one another through multi-threading are in charge of listening for a specific event coming from the [`Emitter`](/main-contracts/ethereum/emitter.md) contract deployed to Ethereum. These files will review all transactions sent to a particular Account in case one hasn't been automatically redeemed as part of Arbitrum's auto-redeem of [retryable tickets](https://developer.arbitrum.io/arbos/l1-to-l2-messaging#retryables). In case it finds one, it manually redeems it. 

## Structure

<figure><img src="/files/xFeFL4T2RK4wiHvFX1hc" alt=""><figcaption><p>Internal subnetwork of Akash deployments</p></figcaption></figure>

Each group of files is containerized and submitted as one deployment to the [Akash network](https://akash.network/). There are N amount of Akash deployments in case one provider fails, since the network doesn't support load balancing at the moment.

* [`event-listener`](https://github.com/cdgmachado0/ozel-listener/blob/main/event-listener.js) listens for new transactions coming from [`Emitter`](/main-contracts/ethereum/emitter.md). Once it gets one, it filters out the Account that was involved in the transaction, adds it to the back of the queue of Accounts to check (if it hasn't been added already), and forwards the queue to `while-fork`.&#x20;
* [`while-fork`](https://github.com/cdgmachado0/ozel-listener/blob/main/while-fork.js) grabs the Account at the beginning of the queue and waits 60 seconds before sending it to `redeem-fork`. These seconds are needed to give [Gelato's subgraph](https://thegraph.com/explorer/subgraphs/LLMtDiq5u1BkbrEN2fhMtCNmR3euSjaQWWRM2tBsMJG?view=Overview) enough spare time to index the new L1 transaction that just occurred.&#x20;
* [`redeem-fork`](https://github.com/cdgmachado0/ozel-listener/blob/main/redeem-fork.js) gets the Account from `while-fork`, and start checking each new transaction that hasn't been checked before for one that wasn't manually redeemed. If it finds one, the EOA associated to these deployments redeems it.&#x20;

#### Considerations

* It needs to be an EOA who does the redeems since the `redeem` function from Arbitrum can't be called by a contract.&#x20;
* All of the actions within the three files happen at the same time.&#x20;

## Assumptions and internal logging

It's worth noting that the most probable, but still unlikely, cause of auto-redeem failure is insufficiency of L2 gas price submitted when creating the retryable ticket.&#x20;

If a transaction is manually redeemed, it gets stored in the [`RedeemedHashes`](/main-contracts/arbitrum/v1/redeemedhashes.md) contract, in Arbitrum, for future queries.&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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.ozelprotocol.xyz/akash/deployments.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.