fix and push

Author: tac0turtle

docs/concepts/block-lifecycle.md

@@ -320,7 +320,7 @@ flowchart TD
     E --> K[Multiply Gas Price by GasMultiplier]
 
     G --> L[Double Backoff Time]
-    G --> M[Cap at MaxBackoff - BlockTime]
+    G --> M[Cap at MaxBackoff - DABlockTime]
 
     H --> N[Split into Two Halves]
     N --> O[Submit First Half]
@@ -655,46 +655,7 @@ The components communicate through well-defined interfaces:
 
 ## Metrics
 
-The block components expose comprehensive metrics for monitoring through the shared Metrics instance:
-
-### Block Production Metrics (Executor Component)
-
-- `last_block_produced_height`: Height of the last produced block
-- `last_block_produced_time`: Timestamp of the last produced block
-- `aggregation_type`: Current aggregation mode (normal/lazy)
-- `block_size_bytes`: Size distribution of produced blocks
-- `produced_empty_blocks_total`: Count of empty blocks produced
-
-### DA Metrics (Submitter and Syncer Components)
-
-- `da_submission_attempts_total`: Total DA submission attempts
-- `da_submission_success_total`: Successful DA submissions
-- `da_submission_failure_total`: Failed DA submissions
-- `da_retrieval_attempts_total`: Total DA retrieval attempts
-- `da_retrieval_success_total`: Successful DA retrievals
-- `da_retrieval_failure_total`: Failed DA retrievals
-- `da_height`: Current DA retrieval height
-- `pending_headers_count`: Number of headers pending DA submission
-- `pending_data_count`: Number of data blocks pending DA submission
-
-### Sync Metrics (Syncer Component)
-
-- `sync_height`: Current sync height
-- `da_included_height`: Height of last DA-included block
-- `soft_confirmed_height`: Height of last soft confirmed block
-- `header_store_height`: Current header store height
-- `data_store_height`: Current data store height
-
-### Performance Metrics (All Components)
-
-- `block_production_time`: Time to produce a block
-- `da_submission_time`: Time to submit to DA
-- `state_update_time`: Time to apply block and update state
-- `channel_buffer_usage`: Usage of internal channels
-
-### Error Metrics (All Components)
-
-- `errors_total`: Total errors by type and operation
+The block components expose Prometheus metrics for monitoring block production, DA submission/retrieval, sync progress, and errors. See the [Metrics guide](/guides/metrics) for configuration and available metric names.
 
 ## Implementation
 

docs/concepts/data-availability.md

@@ -57,7 +57,6 @@ Evolve uses DA namespaces to organize data:
 |-----------|---------|
 | Header | Block headers |
 | Data | Transaction data |
-| Forced Inclusion | User-submitted transactions |
 
 ## Best Practices
 

docs/getting-started/choose-your-path.md

@@ -1,6 +1,6 @@
-# Implement Executor Interface
+# Executor Interface
 
-Deep dive into each method of the Executor interface.
+The Executor interface is the boundary between ev-node and your execution layer. ev-node calls these methods during block production and synchronization. This page documents each method, its contract, and example implementations.
 
 ## Interface Overview
 
@@ -219,4 +219,6 @@ func TestExecuteTxs(t *testing.T) {
 ## Next Steps
 
 - [Executor Interface Reference](/reference/interfaces/executor) — Full type definitions
-- [Testapp Source](https://github.com/evstack/ev-node/tree/main/apps/testapp) — Working example
+- [Testapp Source](https://github.com/evstack/ev-node/tree/main/apps/testapp) — Reference implementation
+- [EVM Quickstart](/getting-started/evm/quickstart) — Using the EVM executor (ev-reth)
+- [Cosmos SDK Quickstart](/getting-started/cosmos/quickstart) — Using the Cosmos SDK executor (ev-abci)

docs/getting-started/custom/implement-executor.md

@@ -1,6 +1,6 @@
 # Based Sequencing
 
-Based sequencing is a decentralized sequencing model where transaction ordering is determined by the base layer (Celestia) rather than a centralized sequencer. In this model, the sequencer derives the next batch of transactions deterministically from the base layer, removing its ability to censor or reorder transactions.
+Based sequencing is a sequencing model where transaction ordering is determined by the base layer (Celestia). Even in based mode, the chain still uses a single sequencer node, but it deterministically derives the next batch of transactions from the base layer rather than choosing its own ordering. This removes the sequencer's ability to censor or reorder transactions.
 
 ## How Based Sequencing Works
 

docs/getting-started/custom/quickstart.md

@@ -86,44 +86,3 @@ If a sequencer fails to include forced inclusion transactions past their epoch b
 2. **Reject invalid blocks** - do not build on top of censoring blocks
 3. **Log the violation** with transaction hashes and epoch details
 4. **Halt consensus** - the chain cannot progress with a malicious sequencer
-
-### Recovery from Malicious Sequencer
-
-When a malicious sequencer is detected (censoring forced inclusion transactions):
-
-Nodes may require a coordinated restart into based sequencing mode, depending on governance and operator policy.
-
-```bash
-# One possible coordinated recovery action
-./evnode start --evnode.node.aggregator --evnode.node.based_sequencer
-```
-
-**In based sequencing mode:**
-
-- No single sequencer controls transaction ordering
-- Every full node derives blocks independently from the DA layer
-- Forced inclusion becomes the primary (and only) transaction submission method
-- Censorship becomes impossible as ordering comes from the DA layer
-
-**Important considerations:**
-
-- Operators should agree on the last valid state and restart timing before the cutover.
-- All full nodes should coordinate the switch to based mode
-- The chain continues from the last valid state
-- Users submit transactions directly to the DA layer going forward
-- Returning to single sequencer mode requires explicit governance and operational coordination
-
-See [Based Sequencing documentation](./based-sequencing.md) for details on operating in this mode.
-
-## Advantages
-
-- **Simplicity:** Easy to set up and operate, making it ideal for development, testing, and small-scale deployments compared to other more complex sequencers.
-- **Low Latency:** Fast block production and transaction inclusion, since there is no consensus overhead among multiple sequencers.
-- **Independence from DA block time:** The sequencer can produce blocks on its own schedule, without being tied to the block time of the DA layer, enabling more flexible transaction processing than DA-timed sequencers.
-- **Forced inclusion fallback:** Users can always submit transactions via the DA layer if the sequencer is unresponsive or censoring.
-
-## Disadvantages
-
-- **Single point of failure:** If the sequencer goes offline, block production stops (though the chain can transition to based mode).
-- **Trust requirement:** Users must trust the sequencer to include their transactions in a timely manner (mitigated by forced inclusion).
-- **Censorship risk:** A malicious sequencer can temporarily censor transactions until forced inclusion activates or the chain transitions to based mode.