> For the complete documentation index, see [llms.txt](https://docs.ethosis.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethosis.org/risk/sequencer-and-chain.md).

# When the chain fails

Robinhood Chain is an Arbitrum Nitro rollup whose single sequencer is run by Robinhood. For an L2 at this stage that is the usual arrangement, but it brings particular ways of failing, and a lending protocol has to be built for them rather than assume they will not happen.

## Failure modes

| Scenario                          | What users experience                                                                                                         |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| The sequencer goes down           | Nothing is included on the L2 until it returns, while the underlying market keeps trading.                                    |
| The sequencer censors             | Particular transactions, a repayment for instance, are left out.                                                              |
| Slow L1 finality                  | Withdrawals to Ethereum take the standard 7 days. Loan operations on the L2 are unaffected.                                   |
| The chain's configuration changes | A change of DA mode or validator set, or switching on Timeboost or BoLD, could alter assumptions about finality and ordering. |

## Defences

### A pause on liquidations after downtime

`PriceGate` consults the Chainlink L2 Sequencer Uptime Feed. Once the feed shows the sequencer has only just returned, starting a liquidation auction is blocked for a grace period of **one hour**. Borrowers get that window to add collateral or repay before anyone can act on a price that moved while no one could transact.

### The L1 delayed inbox reaches every function

Any state-changing function in Ethosis can be submitted via Arbitrum's delayed inbox on Ethereum, and if the sequencer has not included the transaction within 24 hours it can be force-included. Concretely:

* a sequencer that censors cannot stop a borrower repaying,
* a sequencer that censors cannot stop a lender cancelling an offer,
* a borrower expecting an outage can queue a top-up from L1 in advance.

Together with the grace period this makes force inclusion a practical route, not a theoretical one.

### Time is measured in timestamps

On Arbitrum-stack chains `block.number` reports a value derived from L1. For that reason interest accrual, expiries and auction curves depend on `block.timestamp` alone. Where an L2 block height is actually required, the protocol calls `ArbSys.arbBlockNumber()`.

### Keeping calldata small

The L1 data portion of gas is charged on compressed calldata size. Offer structs are packed densely and signatures are supplied in the compact 64-byte form wherever possible, which keeps an `originate` call carrying twenty offers affordable.

## Watching the chain's configuration

Two things depend on whether Timeboost (express-lane ordering) or BoLD (permissionless validation) is turned on for Robinhood Chain: the ordering of liquidators during an auction, and how soon a force-included transaction can be relied on. Ethosis monitors both. Should Timeboost be enabled, the auction design is reviewed to make sure express-lane access cannot systematically front-run keeper transactions, and any resulting change is published in the governance log.


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.ethosis.org/risk/sequencer-and-chain.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.