# MIP-27: Supernova - Sub‑second Finality

**URL:** <https://agora.multiversx.com/t/mip-27-supernova-sub-second-finality/514>\
**Category:** MIPs\
**Created:** [August 18, 2025, 11:56am UTC](https://agora.multiversx.com/t/mip-27-supernova-sub-second-finality/514 "2025-08-18T11:56:47Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![adrian](https://avatars.discourse-cdn.com/v4/letter/a/82dd89/32.png) [@adrian](https://agora.multiversx.com/u/adrian)\
**Post date:** [August 18, 2025, 11:56am UTC](https://agora.multiversx.com/t/mip-27-supernova-sub-second-finality/514/1 "2025-08-18T11:56:47Z")

</div>

- **MIP** : 27
- **Title** : Supernova - Sub‑second Finality
- **Status** : Discussion Draft (Agora)
- **Category** : Core / Protocol
- **Created** : [2025‑08‑14]
- **Requires** : Andromeda (MIP‑25); Barnard
- **Replaces** : -

* * *

## 1. Summary (TL;DR)

Supernova reduces transaction **time‑to‑finality to sub‑second** by (a) cutting the **block slot from 6 s → 600 ms (initial)** and (b) switching the protocol from **Execute‑then‑Propose/Vote** to **Propose/Vote‑then‑Execute** , so consensus no longer waits for execution. Execution results are **usually notarized in the next block** and may be batched if they catch up.

**Key outcomes**

- **Faster inclusion & finality:** 10× tighter proposal cadence; consensus path is shorter (no pre‑proposal execution).
- **Deterministic inclusion of results:** new **Execution‑Result Inclusion Estimator (EIE)** decides how many results are safe to notarize in the header.
- **Header/schema updates:** block headers notarize previous execution results; support for **multiple results per header** and a succinct **LastExecutionResultInfo**.
- **Throughput & utilization:** block gas capacity managed via **estimated gas** with **reactive down‑adjustments** ; gross over‑estimation penalties already lowered in Barnard.
- **Economics unchanged:** end‑of‑epoch emission schedule **remains identical** ; calculations adjusted for variable rounds.

* * *

## 2. Motivation & Problem Statement

- **Why now:** Andromeda removed confirmation blocks and lowered finality. The remaining bottleneck is the synchronous execution that stalls proposals. Supernova removes execution from the consensus‑critical path while keeping safety.
- **Goals:** sub‑second finality (measured from _proposal_ to _irreversible_), predictable inclusion, high utilization, deterministic rules implementable by min‑spec validators.
- **Non‑goals:** changing the inflation schedule; altering ESDT/NFT semantics; immutable miniblocks (considered future work).

* * *

## 3. Scope of Change

- **Consensus/Finality:** Propose/Vote happens before execution; proof creation can be done by any validator; blocks final once \>2/3 votes exist.
- **Cross‑shard execution:** unchanged flow, but results notarized on subsequent headers; receiver‑side execution continues as today. Next round notarization of execution results on meta chain considered for a future release (similar to consensus proofs).
- **Economics:** round‑count‑aware end‑of‑epoch calculations so epoch inflation remains unchanged; fee burn continues to offset emissions.
- **Protocol Parameters:** initial **600 ms** slot; gas capacity stated in **estimated gas** with reactive control; ms‑precision timestamps.
- **Node software & networking:** EIE added; txpool gains virtual‑state tracking for pending proposals.
- **VM & Smart Contracts:** time hooks switch to **millisecond timestamps** after an activation epoch.
- **APIs / Indexers / SDKs:** header schema extended with notarized results and `LastExecutionResultInfo`.

* * *

## 4. Technical Specification

### 4.1 Consensus & Finalization

- **Andromeda (baseline):** consensus after verification + (normal) execution + vote propagation; scheduled execution runs in parallel and does not delay finality.
- **Supernova:** the proposer constructs a block from cross‑shard miniblocks and txpool selections **without prior execution** , sends it for voting, then queues the proposal for execution. Validators verify proposal rules and vote immediately; they also queue the proposal for execution locally. With \>2/3 votes the block is **final** ; execution results are typically notarized **in the next header**.
- **Finality measurement:** aligned with other L1s (e.g., Solana Alpenglow) - **from proposal dissemination to irreversibility**.

### 4.2 Execution & Results in Headers

- **Scheduled execution** and **partial mini blocks execution** are **deactivated** in Supernova, as they are not needed for the propose‑then‑execute flow.
- **Partial mini blocks no longer needed** as execution does not need to finish before proposal or risk failing the block. **Scheduled execution is now the default** through propose/vote then execute, but before transitioning to the new schemas all previous scheduled execution must be finalized.
- Previously combined **Execute-and-Propose** functionality split into **Propose** , **Validate Proposal** , and **Execute Proposal**
- **Execute Proposal is now common flow** for both proposer and validators reducing disparity between proposer and validators.
- Each header (execution shards & metachain) includes **notarization of prior execution results**. This is similar to how previous block scheduled execution results were part of the next header reported results in Andromeda (and previous versions).
- **Multiple results per header** are allowed to cover catch‑up scenarios; a succinct `LastExecutionResultInfo` is provided.
- **Miniblocks in results** reference final states (invalid/unpayable txs removed at execution time). Moving to _immutable miniblocks_ is deferred.

### 4.3 Execution‑Result Inclusion Estimator (EIE)

- **Purpose:** decide, at proposal/validation time, how many pending results can be safely included so that a **min‑spec node** can finish execution of all referenced blocks before it must validate the new block.
- **Deterministic inputs:** pending results (nonce order), last notarized result time, `T_gas` (e.g., **1 ns per gas** ), safety margin `μ`, `MaxResultsPerBlock`.
- **Computation (high‑level):** accumulate `ET += Δgas * T_gas` over pending results; compute `t_done = t_base + ET * (1 + μ)`; include results until `t_done` exceeds the current header time (or the max count is reached).
- **Outputs:** allowed count [0..N] to embed in the header.

### 4.4 Gas Capacity & Utilization

- **Problem:** proposals use **estimated gas** ; over‑estimation can under‑fill blocks.
- **Countermeasures:** (i) **lower gross‑overestimation penalty** (Barnard: threshold from \>10× to \>2×), (ii) **over‑estimate block capacity** to mask moderate overages, (iii) **reactive down‑adjust** of per‑block limits when proposal→result gaps appear.
- **Initial capacity:** for a 600 ms slot, **1.2B estimated gas** per block (min‑spec hardware target).

### 4.5 Protocol Parameters (Before → After)

| Parameter | Current (Andromeda + Barnard) | Supernova (Initial) | Notes |
| --- | --- | --- | --- |
| **Block slot** | 6 s | **600 ms** | Synchronized change; see §10.2 |
| **Finality rule** | Proof after vote (may include normal exec) | Proof after vote (exec decoupled) | Results notarized next header |
| **Finality estimation** | 100ms → 1.6s (empirical data) | **100ms → 250ms** | Time from proposal dissemination until irreversibility |
| **Header** | Prior scheduled execution result notariz | Prior **execution results notarized** ; supports multiple execution results | contains also `LastExecutionResultInfo` |
| **Gas per block** | Mix of real (normal) + est. (scheduled/x‑shard) | **Estimated‑gas based** , **1.2B est. gas** target | Reactive down‑adjust |
| **Over‑estimation penalty** | \>2× (Barnard) | **\>2×** (Barnard) | Already live |
| **Timestamp resolution** | Seconds | **Milliseconds** | Activates at epoch boundary |

### 4.6 TxPool & Selection Logic (Supernova)

**Overview.** In Supernova, each block carries _(a)_ **transactions selected for subsequent execution** and _(b)_ the **execution outcome of previously selected** transactions. A leader **must not re‑select** transactions that were already selected in earlier proposed blocks (even if those have not executed yet).

**Notifications.** To keep selection consistent with the evolving chain state, the mempool subscribes to two notifications from the processing pipeline:

- `mempool.onProposedBlock(block)` - informs about transactions **selected/proposed** in `block`.
- `mempool.onExecutedBlock(block)` - informs about transactions **executed** in `block` and their outcomes.

**Selection tracker.** Internally, the mempool maintains a **selection tracker** - a collection of _block metadata_ (a.k.a. _tracked blocks_). Each block metadata holds a map of **account breadcrumbs** for every seen **sender/relayer** in that block.

**Breadcrumbs.** When `onProposedBlock`/`onExecutedBlock` arrives, the mempool **walks the block’s transactions** and, for each sender/relayer, compiles a breadcrumb with:

- **first nonce** and **last nonce** observed in that block;
- **consumed balance** in the scope of that block (processing fee accounting).

Minimal validation is done when compiling breadcrumbs (e.g., **contiguous nonce spans** ).

**Virtual state derivation at selection start.** Given the current **blockchain `rootHash`** and the set of **tracked blocks whose results are not yet captured on‑chain** , the mempool derives, by following breadcrumbs, per‑account tuples:

- `{address, initialNonce, initialBalance, consumedBalance}`.

These tuples seed a **virtual `SelectionSession`** (existing _Spica_ concept) so the selector can **skip non‑executable transactions** deterministically (e.g., **nonce gaps** or **insufficient balance for processing fees** ). The derivation is performed **at the beginning of each selection**.

**Selection algorithm.** The **core selection algorithm (Spica)** remains largely unchanged; it now operates over the **virtual account state** supplied by the selection tracker to produce a proposal that is executable once results catch up.

**Lifecycle & updates.**

- The selection tracker is **only updated via notifications** (`onProposedBlock` / `onExecutedBlock`). It is **not** mutated at the end of a selection.
- **Deletion of transactions** remains the responsibility of processing components, as before Supernova.
- This keeps selection **deterministic and side‑effect free** , and prevents leaders from re‑selecting already proposed transactions.

**Invariants.** A leader’s proposal **must reflect** breadcrumb knowledge: do not re‑select previously proposed txs from the same account if it would create a **nonce gap** or exceed **available balance** in the virtual state.

### 4.7 APIs / Tooling

- **ApiBlock stays the façade.** The **existing `ApiBlock`** (used pre‑Supernova) continues to decouple protocol internals from public API output.
- **New field: `LastExecutionResult`.** `ApiBlock` now includes **`LastExecutionResult`** , which holds the notarized execution result corresponding to the latest block state. Internally, first‑level fields such as **`rootHash`** and **`validatorStateRootHash`** are removed from the protocol block structure and are **embedded inside `LastExecutionResult` / `ExecutionResult`**.
- **Compatibility behavior.** For a **transition window** , `ApiBlock` will continue to expose the **legacy top‑level fields** (`rootHash`, `validatorStateRootHash`) by **populating them from `LastExecutionResult` / `ExecutionResult`**. This allows existing consumers to keep working unchanged while migrating to the new fields.
- **Augmented schema.** `ApiBlock` also exposes the new **execution‑result notarization references** (including support for **multiple results per header** ) and the compact **`LastExecutionResultInfo`**.
- **Changelogs & sunset.** The re‑interpretation of legacy fields and the eventual **deprecation timeline** will be documented. External API providers should switch to reading **`LastExecutionResult` / `ExecutionResult`** as the **source of truth**.
- **SDKs.** Minimum versions TBA; changelogs will detail field additions and any re‑interpretations or deprecations.

* * *

## 5. Rationale & Design Trade‑offs

- **Latency vs Utilization:** decoupling execution yields sub‑second finality; estimated‑gas fitting plus reactive control protects utilization.
- **Determinism & Safety:** EIE ensures headers never reference results that min‑spec validators could not have finished.
- **Complexity:** header/result structures grow modestly; immutable miniblocks deferred to limit scope.
- **Bandwidth:** half‑split between **incoming cross‑shard** vs **intra/outgoing** to preserve liveness and fairness during congestion.

* * *

## 6. Security Considerations

- **Byzantine assumptions** unchanged; decoupling does not relax quorum thresholds.
- **Equivocation prevention:** notarized execution results are tied to header hashes/nonces; multiple‑result support avoids liveness stalls.
- **DoS surfaces:** reactive gas caps mitigate pathological estimation; txpool virtual state reduces proposal churn.

* * *

## 7. Backwards Compatibility

- **Smart contracts:** time‑related hooks switch to **ms precision** at activation; no ABI or host‑function changes in this release.
- **Protocol vs API structures:** protocol‑internal block/header structures change to carry **notarized execution results** (supporting **multiple results per header** ) and a compact `LastExecutionResultInfo`. The public **`ApiBlock`** adapts by **adding the new `LastExecutionResult` field** and by **deriving legacy fields** (e.g., `rootHash`, `validatorStateRootHash`) **from `LastExecutionResult`/`ExecutionResult`** during a **transition window** so existing consumers remain functional.
- **Indexers / explorers / bridges / wallets:** internally maintained components will be updated in lock‑step. External providers should adapt to the augmented `ApiBlock` schema; during the transition both legacy fields (derived) and new fields will be available. A **deprecation epoch** will be announced ahead of removal of compatibility behavior.
- **Transactions/serialization:** unchanged on the wire; only header content expands to include notarized references.

* * *

## 8. Performance Expectations & Benchmarks

- **Targets:** sub‑second finality measured **proposal → irreversible** ; high inclusion rate under load.
- **Observed:** methodology to mirror §4.1 definition.
- **Resource impact:** CPU/RAM/disk/bandwidth deltas on validators.

* * *

## 9. Stakeholder Impact

- **Validators/SPs:** new client with EIE; minor config for reactive gas cap; monitor proposal→result gap metric.
- **Delegators/Stakers:** no change to emission schedule; APR drivers unchanged except fee‑driven deflation.
- **Developers:** no contract changes required; SDKs to read new header fields.
- **Users/Wallets:** faster apparent finality; UX updates in xPortal to reflect definition.

* * *

## 10. Deployment & Rollout Plan

### 10.1 Testnet Phases

- **Phase A:** ms timestamps; deactivation of new partial mini blocks and scheduled mini blocks proposals (continue with already started partial mini blocks execution) ; success: stable indexing, all partial and scheduled execution finalized before next phase.
- **Phase B:** 600 ms slot; EIE on, header/result schema behind flags, propose/vote then execute; success: proposal→result gap bounded; validators at target CPU, no safety violations, acceptable orphan rate.

### 10.2 Activation & Feature Flags (Mainnet)

- **Epoch E:** switch **timestamp precision to milliseconds** for all shards.
- **Synchronized Round K (post‑epoch):** switch **slot duration 6 s → 600 ms** on all shards to keep round numbers consistent; metachain notarizes only headers that respect the transition (no nonce gaps; within grace window); header/result schema updated, propose/vote then execute.
- **Compatibility window:** RPC/indexers parse both schemas during soak.

### 10.3 Validator Upgrade Steps

1. Use provided scripts to upgrade validators to the new client version.
2. Post‑upgrade: sync/peers/CPU/mem; monitor proposal→result gap and execution backlog.

* * *

## 11. Monitoring & Success Metrics

- **On‑chain KPIs:** finality (proposal→irreversible), orphan rate, proposal→result gap, cross‑shard latency.
- **Node health:** CPU, RAM, bandwidth; EIE decisions.

* * *

## 12. Risks & Open Questions

- Tuning of `μ`, `T_gas`, and `MaxResultsPerBlock`.
- Throughput vs latency under adversarial gas estimation.
- Indexers readiness; explorers UI for new result fields.
- Future work: immutable miniBlocks & bandwidth optimizations, next round execution results notarization on metachain.

* * *

## 13. References

- Andromeda (MIP‑25); Barnard penalties.
- Finality measurement aligned to broader L1 practice

* * *

## 14. Appendix

### A. Glossary

- **EIE:** Execution‑Result Inclusion Estimator.
- **API:** Application Programming Interface.
- **SDK:** Software Development Kit.
- **Txpool:** Transaction pool.
- **Nonce gap:** A gap in the sequence of nonces for a given account.
- **Miniblock:** A block containing a subset of transactions, typically used in cross‑shard execution.
- **Virtual state:** A simulated state of accounts used for transaction selection.

### B. Internal Schemas

#### Shard Blocks Execution Results

```go
type BaseExecutionResult struct {
    HeaderHash []byte
    HeaderNonce uint64
    HeaderRound uint64
    RootHash []byte
}

type ExecutionResult struct {
    BaseExecutionResult *BaseExecutionResult
    ReceiptsHash []byte
    MiniBlockHeaders []MiniBlockHeader
    DeveloperFees *math_big.Int
    AccumulatedFees *math_big.Int
    GasUsed uint64
    ExecutedTxCount uint64
}

```

#### Meta Blocks Execution Results

```go
type BaseMetaExecutionResult struct {
    BaseExecutionResult *BaseExecutionResult
    ValidatorStatsRootHash []byte
    AccumulatedFeesInEpoch *math_big.Int
    DevFeesInEpoch *math_big.Int
}

type MetaExecutionResult struct {
    ExecutionResult *BaseMetaExecutionResult
    MiniBlockHeaders []MiniBlockHeader
    ReceiptsHash []byte
    DeveloperFees *math_big.Int
    AccumulatedFees *math_big.Int
    GasUsed uint64
    ExecutedTxCount uint64
}

```

#### Succinct Data for Keeping Track of Last Execution Result

```go
type MetaExecutionResultInfo struct {
    NotarizedOnHeaderHash []byte
    ExecutionResult *BaseMetaExecutionResult
}

type ExecutionResultInfo struct {
    NotarizedOnHeaderHash []byte
    ExecutionResult *BaseExecutionResult
}

```

### C. Algorithms

#### Execution‑Result Inclusion Estimator (EIE)

```pseudo
1. let ET ← 0 // accumulated execution time (ns)
2. let t_base ← (if lastNotarised == nil
    then genesisTimestampMs * 10^6 // convert to ns
    else lastNotarised.HeaderTimeMs * 10^6)
3. for i, res ∈ pending (in nonce order):
4. Δgas ← res.GasUsed
5. ET += Δgas * T_gas // 1 ns per gas
6. t_done ← t_base + ET * (1 + μ)
7. if t_done > currentHdrTsMs * 10^6: // convert to ns
8. return i // cannot include res and beyond
9. if cfg.MaxResultsPerBlock ≠ 0 and i+1 ≥ cfg.MaxResultsPerBlock:
10. return i+1
11. return len(pending)

```

At step 6. ET is multiplied by a safety margin (default 1.1 - adding an extra 10%) to give even more buffer (10%) for slower validators.