# Lifecycle of an Eclipse Transaction

{% @mermaid/diagram content="sequenceDiagram
participant User
participant Eclipse Node
participant GSVM
participant Celestia
participant Ethereum
participant RISCZero

```
User->>Eclipse Node: Submit Transaction
Eclipse Node->>Eclipse Node: Filter, Pre-confirm, State Prefetch
Eclipse Node->>GSVM: Sequencing and Execution
GSVM-->>Eclipse Node: Execution Results
Eclipse Node->>Celestia: Publish Transaction Data
Eclipse Node->>Ethereum: Submit State Commitments
Note over Eclipse Node, RISCZero: Fraud Proof Window" fullWidth="true" %}
```

This section illustrates the full path of a transaction within Eclipse—from user submission to final settlement. The system modularly separates responsibilities across five actors: the user, the Eclipse Node, GSVM for execution, Celestia for data availability, Ethereum for final settlement, and RISC Zero for provable security.

1. **User Submission**: A transaction is initiated by a user and submitted to an Eclipse Node.
2. **Preprocessing**: SmartNICs and FPGAs kick in to filter, deduplicate, and locally pre-confirm transactions. Relevant state is prefetched into memory to minimizse latency during execution.
3. **Sequencing:** Transactions are ordered using a mix of performance-based and application-specific logic. When traffic spikes occur in particular applications, like AMMs or games, Eclipse creates Hotspot Islands to isolate those workloads on dedicated threads.
4. **Execution**: GSVM executes the transaction using a hybrid concurrency model. It combines optimistic and pessimistic paths to ensure both speed and safety. The runtime also learns and improves over time based on real workloads.
5. **DA Publishing**: Executed transaction data is batched and published to Celestia through the Celestia Publisher. Celestia handles erasure-coding and inclusion into a Merkle tree, which is later referenced on Ethereum.
6. **Settlement**: Once data is available, the state commitment is finalized and posted to Ethereum, ensuring long-term finality.
7. **Fraud Window**: If any fraudulent activity is suspected, RISC Zero can generate a fraud proof. This proof is submitted to Ethereum to challenge and revert invalid state transitions.


---

# 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.eclipse.xyz/architecture/eclipse-architecture/lifecycle-of-an-eclipse-transaction.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.