> ## Documentation Index
> Fetch the complete documentation index at: https://docs.initia.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Challenger

The Challenger is a process distinct from the Executor, responsible for
monitoring the Executor's output proposals and challenging any invalid
submissions. This ensures the integrity of the rollup's state and prevents
malicious actions by the Executor.

The primary responsibilities of the Challenger include:

1. **Verifying Deposits**:
   * Ensure that the `MsgInitiateTokenDeposit` event is relayed correctly to the
     `MsgFinalizeTokenDeposit` event.
   * Check if `MsgInitiateTokenDeposit` was relayed within the required time
     frame.
2. **Verifying Oracle Updates**:
   * Confirm that Oracle data is correctly relayed to `MsgUpdateOracle`.
   * Ensure that Oracle updates are processed on time.
3. **Validating Outputs**:
   * Check that the `OutputRoot` submitted with `MsgProposeOutput` is accurate.
   * Ensure that the next `MsgProposeOutput` is submitted within the expected
     time frame.

## Detailed Architecture

The Challenger architecture is designed to ensure that interactions between
Initia (L1) and rollup (L2) are correctly validated, securing internal processes
within the Initia ecosystem. Each part of the architecture is tailored to handle
specific challenges while maintaining the security and reliability of the
Initia-rollup interactions.

### Deposit Challenges

Deposits from L1 to L2 must follow a strict verification process to ensure that
tokens are correctly transferred between chains.

The Challenger plays a critical role in this by confirming that
`MsgInitiateTokenDeposit` is not only correctly triggered but also completed
within a specific timeframe by matching it to `MsgFinalizeTokenDeposit`.

This prevents potential discrepancies or fraud, ensuring that deposits are
secure.

When a `MsgInitiateTokenDeposit` event is detected on the L1 chain, it is
recorded as a **Deposit** challenge.

The system checks if it matches the `MsgFinalizeTokenDeposit` event for the same
sequence.

```go theme={null}
// Deposit is the challenge event for deposit data
type Deposit struct {
	EventType     string    `json:"event_type"`
	Sequence      uint64    `json:"sequence"`
	L1BlockHeight uint64    `json:"l1_block_height"`
	From          string    `json:"from"`
	To            string    `json:"to"`
	L1Denom       string    `json:"l1_denom"`
	Amount        string    `json:"amount"`
	Time          time.Time `json:"time"`
	Timeout       bool      `json:"timeout"`
}
```

### Output Challenges

**Outputs**, which represent state changes in the L2 chain, must be correctly
submitted to maintain the synchronization between L1 and L2.

The Challenger ensures that the OutputRoot of the submitted `MsgProposeOutput`
matches the system’s expectations and that future proposals are made within the
designated timeframe.

This process prevents any incorrect or malicious outputs from being finalized,
ensuring the integrity of the system.

When a `MsgProposeOutput` event is detected on the L1 chain, it triggers an
**Output** challenge.

The system replays up to the L2 block number and verifies whether the
`OutputRoot` matches the one submitted.

```go theme={null}
// Output is the challenge event for output data
type Output struct {
	EventType     string    `json:"event_type"`
	L2BlockNumber uint64    `json:"l2_block_number"`
	OutputIndex   uint64    `json:"output_index"`
	OutputRoot    []byte    `json:"output_root"`
	Time          time.Time `json:"time"`
	Timeout       bool      `json:"timeout"`
}
```

### Oracle Challenges

Oracles serve as external data providers for the blockchain, and any failure in
updating their data can lead to inaccuracies within the system.

The Challenger ensures that oracle updates happen in a timely manner and are
properly relayed from L1 to L2 through `MsgUpdateOracle`, safeguarding the
accuracy of external data within the Initia ecosystem.

If the `oracle_enable` setting is turned on in bridge config, the 0th
transaction's bytes are saved as an **Oracle** challenge event.

This data is verified against the `MsgUpdateOracle` for the same L1 height.

```go theme={null}
// Oracle is the challenge event for oracle data
type Oracle struct {
	EventType string    `json:"event_type"`
	L1Height  uint64    `json:"l1_height"`
	Data      []byte    `json:"data"`
	Time      time.Time `json:"time"`
	Timeout   bool      `json:"timeout"`
}
```

### Rollback Challenges (TBA)

If a challenge is created and the event is not finalized within the timeout
period, it is possible to rollback before the challenge is finalized. This
feature will be announced in a future release.