bnb-chain · buddh0 · Sep 25, 2025 · Sep 11, 2025 · Sep 19, 2025 · Sep 24, 2025
diff --git a/BEPs/BEP-619.md b/BEPs/BEP-619.md
@@ -0,0 +1,115 @@
+<pre>
+  BEP: 619
+  Title: Short Block Interval Phase Three: 0.45 Seconds
+  Status: Draft
+  Type: Standards
+  Created: 2025-09-11
+  Description: To shorten the block interval from 0.75 seconds to 0.45 seconds.
+</pre>
+
+# BEP-619: Short Block Interval Phase Three: 0.45 Seconds
+- [BEP-619: Short Block Interval Phase Three: 0.45 Seconds](#bep-619-short-block-interval-phase-three-045-seconds)
+  - [1. Summary](#1-summary)
+  - [2. Abstract](#2-abstract)
+  - [3. Motivation](#3-motivation)
+  - [4. Specification](#4-specification)
+    - [4.1 Parameter Changes](#41-parameter-changes)
+      - [4.1.1 Change Table](#411-change-table)
+    - [4.2 Extended Voting Rules for Fast Finality Stability](#42-extended-voting-rules-for-fast-finality-stability)
+  - [5. Rationale](#5-rationale)
+    - [5.1 Parameter Changes](#51-parameter-changes)
+  - [6. Backward Compatibility](#6-backward-compatibility)
+    - [6.1 MEV](#61-mev)
+    - [6.2 Quarterly Auto-Burn](#62-quarterly-auto-burn)
+    - [6.3 Block Finality](#63-block-finality)
+  - [7. License](#7-license)
+
+---
+
+## 1. Summary
+
+This proposal shortens the block interval from 0.75 seconds to 0.45 seconds, further improving transaction confirmation speed and enhancing user experience.
+
+## 2. Abstract
+
+* **BEP-520** (Phase One): reduced the block interval from 3 seconds to 1.5 seconds.
+* **BEP-524** (Phase Two): reduced it further to 0.75 seconds.
+* **BEP-619** (Phase Three, this proposal): reduces it to 0.45 seconds.
+
+## 3. Motivation
+
+Reducing the block interval is a long-term goal of BNB Smart Chain. A 0.45-second block interval will support time-sensitive applications by providing significantly faster confirmation times.
+
+## 4. Specification
+
+The overall design follows BEP-524, with modifications only to the relevant parameters.
+
+### 4.1 Parameter Changes
+
+Phases one, two, and three are closely related. For clarity, their parameter changes are consolidated into the following table.
+
+#### 4.1.1 Change Table
+
+Many system parameters are tied to the default block interval. When the interval is adjusted, related parameters must also be updated:
+
+| Parameter                            | Type     | Origin (3s)            | Phase One (1.5s) | Phase Two (0.75s) | Phase Three (0.45s) |
+| ------------------------------------ | -------- | ---------------------- | ---------------- | ----------------- | ------------------- |
+| Epoch                                | client   | 200                    | 500              | 1000              | 1000                |
+| GasLimit                             | client   | 140M                   | 100M             | 75M               | 45M                 |
+| GasLimitBoundDivisor                 | client   | 256                    | 1024             | 1024              | 1024                |
+| FullImmutabilityThreshold            | client   | 90,000                 | 180,000          | 360,000           | 600,000             |
+| receiveRateLimitPerSecond            | client   | 10                     | 20               | 40                | 68                  |
+| Blob Target                          | client   | 3                      | 3                | 3                 | 3                   |
+| Blob Maximum                         | client   | 6                      | 6                | 6                 | 6                   |
+| Blob MinBlocksForBlobRequests        | client   | 524,288                | 1,048,576 (×2)   | 2,097,152 (×4)    | 3,495,254 (×3/0.45) |
+| BSCGovernor.votingPeriod             | contract | \$votingPeriod         | ×2               | ×4                | ×(3/0.45)           |
+| BSCGovernor.minPeriodAfterQuorum     | contract | \$minPeriodAfterQuorum | ×2               | ×4                | ×(3/0.45)           |
+| BSCValidatorSet.misdemeanorThreshold | contract | \$misdemeanorThreshold | ×2               | ×4                | ×(3/0.45)           |
+| BSCValidatorSet.felonyThreshold      | contract | \$felonyThreshold      | ×2               | ×4                | ×(3/0.45)           |
+| BSCValidatorSet.felonySlashScope     | contract | \$felonySlashScope     | ×2               | ×4                | ×(3/0.45)           |
+| BSCValidatorSet.TurnLength           | contract | 4                      | 8                | 16                | 16                  |
+
+`receiveRateLimitPerSecond` is the max number of received votes per second from one peer, used to avoid of DDOS attack.
+
+### 4.2 Extended Voting Rules for Fast Finality Stability
+
+With a shorter block interval, network fluctuations and node performance issues have a larger impact on stability. To improve finality robustness, the adjustments defined in [BEP-590: Extended Voting Rules for Fast Finality Stability](https://github.com/bnb-chain/BEPs/pull/590/files) will also be applied.
+
+---
+
+## 5. Rationale
+
+### 5.1 Parameter Changes
+
+* **GasLimit**: In phases one and two, GasLimit did not decrease proportionally with block interval reductions, due to hardware and software optimizations. In phase three, GasLimit is adjusted proportionally to match the reduced interval.
+* **Epoch**: Epoch remains at 1000 blocks, reducing epoch time from 750s to 450s. Validator rotation becomes more frequent but is expected to have no negative impact. This also allows more equitable participation opportunities for candidates within a day.
+
+---
+
+## 6. Backward Compatibility
+
+### 6.1 MEV
+
+With a 0.45s block interval, each validator still produces 16 consecutive blocks per turn, reducing total turn time to 7.2s (0.45 × 16). This narrows the collaboration window for searchers, builders, and validators, requiring adjustments to current MEV strategies.
+
+### 6.2 Quarterly Auto-Burn
+
+*TBD.*
+
+### 6.3 Block Finality
+
+The fast finality mechanism remains unchanged. However, shorter intervals reduce the time available for vote propagation.
+
+* **With fast finality working correctly**: transaction finality improves from \~1.875s to \~1.125s.
+* **If fast finality fails** (natural finality with TurnLength=16, ValidatorSize=21):
+
+  * > 1/2 validator confirmations: 176 blocks (11×16) ≈ 79.2s
+  * > 2/3 validator confirmations: 240 blocks (15×16) ≈ 108s
+
+---
+
+## 7. License
+
+This document is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+---
diff --git a/README.md b/README.md
@@ -92,6 +92,7 @@ Here is the list of subjects of BEPs:
 | [BEP-564](./BEPs/BEP-564.md) | bsc/2 - New Block Fetching Messages | Standards | Candidate |
 | [BEP-593](./BEPs/BEP-593.md) | Incremental Snapshot | Standards | Draft |
 | [BEP-594](./BEPs/BEP-594.md) | L2 Fast Withdrawal by TEE | Standards | Draft |
+| [BEP-619](./BEPs/BEP-619.md) | Short Block Interval Phase Three: 0.45 Seconds | Draft |
 
 # BAPs
 BAP (BNB Application Proposal) defines standards for application layer interactions on BNB Chain. Unlike BEPs which govern core protocol changes, BAPs focus on establishing conventions and interfaces for how applications communicate and interact with each other within the BNB Chain ecosystem.