BNB Chain BEP status: Draft, Enabled and when a change goes live

Every BEP (BNB Chain Evolution Proposal) in the BNB Chain GitHub repository carries a Status line near the top. It records how far the proposal has moved through review. It does not record the moment the change started applying on mainnet. That moment comes from somewhere else: the activation time of the hard fork that shipped it, or the block in which an on-chain governance proposal was executed.

The repository offered a clean example on 7 October 2026. BEP-673, the meta-proposal for the Pasteur upgrade, still read Status: Draft. The BNB Chain documentation's upgrade notice gave a mainnet activation time of 2026-08-25 02:30 UTC. Both are official. They simply answer different questions.

What Draft, Review, Candidate and Enabled mean for a BEP

The process is itself a BEP. BEP-1, whose own status is Living, lays out five steps:

• Idea – discussion on the forum or community channels; no number yet.
• Draft – a formatted document is opened as a pull request; once BEP editors review and merge it, it is a BEP, numbered after the PR. The author can keep revising it.
• Review (vote) – community review. Changes touching consensus, the economic framework or user-facing compatibility need a governance vote; minor fixes may skip it.
• Candidate – review passed and the proposal accepted.
• Enabled – live on BNB Chain mainnet; for a hard fork, the fork height or time has been reached.

Three exceptional states sit beside these. Living means maintained long term. Stagnant means no update for more than six months. Withdrawn means dropped, usually because a precondition no longer holds.

One sentence in BEP-1 is easy to skim past: a BEP can still be updated as long as it is not enabled. A parameter you read in a Draft or Candidate may change before launch, so it does not belong in a fee budget yet.

Why the README can say Draft after the mainnet upgrade has happened

Read literally, BEP-1 says the Pasteur entries should become Enabled once the fork activates. But a status is a line of text in a file; it changes only when someone commits the edit. On 2026-10-07 the README index of the BEPs repository still listed BEP-673, BEP-682, BEP-695 and BEP-675 as Draft. Meanwhile the BNB Chain docs announcement menu filed Pasteur under “Passed”, and both the Pasteur upgrade page and the BSC node v1.7.7 release notes gave the mainnet time as 2026-08-25 02:30 UTC.

BEP-658, the Osaka/Mendel meta-proposal from the previous upgrade, already shows Enabled in the same table. Some rows get updated, some lag. Treat the status as a lead and go find the time in the announcement. Do not use a stale Draft to overrule a notice that names an exact activation time.

The mismatch can run the other way too. BEP-95, the real-time burning mechanism, has no Status header block at all; section 3 simply says “This BEP is already implemented.” The README lists it as Enabled. Older proposals predate the current format, so a missing field is not evidence that a change never shipped.

Hard fork BEPs: find the activation time, then see which side a transaction falls on

BEPs that change EVM rules, block structure or fee calculation are normally bundled into a named hard fork, listed by a meta-proposal titled “Hardfork Meta-” plus the fork name. Activation time is the dividing line. Blocks before it follow the old rules; blocks after it follow the new ones.

Take Mendel. The BNB Chain docs give testnet activation at 2026-03-24 02:30 UTC and mainnet at 2026-04-28 02:30 UTC. BEP-652, enabled with it, caps the gas a single transaction may use at 16,777,216 (2^24); anything above is rejected during validation. For anyone setting a gas limit by hand:

• before 28 April, a single transaction had no separate cap of this kind and was bounded mainly by block capacity and other rules;
• after 28 April, the same transaction submitted with a limit of 20,000,000 is rejected at validation. A rejected transaction never enters a block, so no on-chain gas is charged for it (see the first case in the failed-transaction guide).

A plain transfer uses 21,000 gas, roughly 800 times below the cap, so day-to-day activity never gets near it. Heavy transactions are the ones to watch: batched calls or large contract deployments where a limit that used to be accepted can now be refused outright.

Inside one upgrade, BEPs may switch on in different ways. BEP-673 lists BEP-682 and BEP-695 as needing the hard fork and BEP-675 as not needing it, adding that the validator-side SendBidBlock path opens only after Pasteur activates and is controlled through RPC interfaces. Reaching the fork time, then, does not settle whether that path is in use; node operators still have to turn it on.

Jenner, listed under “Upcoming” in the docs, follows the same pattern. Its meta-proposal BEP-718 says the BEP-702 code reaches every node with the hard fork, while token creation on a given network is opened by a governance-appointed activation switch defined in that BEP. The fork is only the first gate.

Parameter changes: after the vote passes, there is still a timelock

Not every change needs a fork. Some rules are written as governable parameters. In BEP-95, validators deposit each block's gas fees into the ValidatorSet system contract, and burnRatio × fee goes to the burn address. The proposal set an initial burnRatio of 10% and stated that validators can change it by vote.

So “how much BEP-95 burns” is not a constant fixed in the proposal. For any period, you need the parameter that was actually in force during that period.

BEP-95 describes voting on BNB Beacon Chain, with a 2,000 BNB deposit and a 50% quorum. Today the BSC governance documentation describes the native module introduced by BEP-297, with different numbers:

• submitting: at least 200 BNB staked, and no pending proposal from the same delegator;
• voting period: currently 7 days, with votes changeable throughout;
• execution: voted stake at least 10% of total staking credit, and Yes at least 50% and no lower than No;
• timelock: once the conditions are met, a further 1-day delay before the proposal can be executed.

Here is the earliest start date those numbers allow, using an invented date purely for the arithmetic. Suppose a parameter proposal opens for voting at 2026-11-02 00:00 UTC. Voting closes seven days later at 2026-11-09 00:00. Even if every condition is met at that instant, the one-day timelock means execution cannot happen before 2026-11-10 00:00. The new value applies from the block containing the execution transaction, not from the end of the vote. The docs do not say whether a delay also precedes voting, so for a real proposal take the start and end blocks from its on-chain record rather than adding up these two figures.

This matters when you reconcile burns. If a reporting window crosses a burnRatio change, split it in two; a single ratio cannot turn total burned BNB back into total gas fees. The Auto-Burn and BEP-95 guide covers how to line up burn records by period.

Which BEPs change your BNB gas or burn figures

Most BEPs deal with nodes, consensus or developer interfaces and rarely touch a holder's fee records. These four bear directly on fees, supply and burning, which makes them good practice material:

• BEP-95 – real-time burning: gas fees reach the burn address according to burnRatio. Affects burn statistics.
• BEP-226 – brings EIP-1559 transactions and headers to BSC with a base fee fixed at 0 that does not move with congestion. Its stated reason is that BEP-95 already burns, so there is no need to burn a base fee. When a BSC transaction shows EIP-1559 fields, Ethereum's “base fee is burned” arithmetic does not apply.
• BEP-652 – the 16,777,216 per-transaction gas cap, enabled on mainnet with Mendel. Affects what gas limit you can set.
• BEP-619 – shortens the block interval from 0.75 to 0.45 seconds; README status Enabled. Its backward-compatibility section has an item titled Quarterly Auto-Burn, yet on 2026-10-07 the only text under it was “TBD”. The proposal itself does not yet say whether faster blocks change the quarterly burn calculation, so any claim about that needs a separate official source.

How to check whether a BEP is actually live: six steps

1. Find the number in the README index of the BEPs repository. Note the title, type (Standards, Information or Process) and status.
2. Open the BEP file and read the header. Some files state activation in the Description field; BEP-1's own format example reads “enabled by BSC Euler upgrade, block height 18907621, Jun-22-2022”.
3. Search the README for the “Hardfork Meta-” proposal that lists it. Meta-proposals split their lists into BEPs that need the hard fork and those that do not.
4. Open the matching upgrade page under Announcements in the BNB Chain docs and note the testnet and mainnet activation times in UTC. Node release notes make a useful second source.
5. For BEPs without a fork, or with switches and governable parameters, find the governance record or operator notice that shows when the switch was turned on or the parameter executed.
6. Write the result as one dated sentence, for example: “BEP-652: README status Enabled; Mendel mainnet activation 2026-04-28 02:30 UTC; checked 2026-10-07.”

Step 6 looks like paperwork. It pays off the next time you look: statuses get corrected and announcement pages get reorganised, and a note of where you read what, and when, shows exactly which part moved.