BNB Chain’s October 22, 2026 Jenner guide names October 28 for BSC testnet, but the linked Reth v0.1.3 release tells Chapel testnet operators to upgrade before October 29 at 02:30 UTC. Those are differently stated milestones. Do not infer an exact activation instant or timezone conversion from the blog date alone. Confirm the instructions for your client and network; the announcement does not establish a completed mainnet rollout.
Reconcile the notice before scheduling a node change
The blog guide says confirmed mainnet timing will be announced separately. The generic upgrade page still gives broad late-October testnet and late-November mainnet windows without exact times. The Reth release supplies its own specific update deadline. Keep the source, network, client and stated action together instead of merging them into one unsupported timestamp.
For an operator, the unresolved point is not solved by choosing the most convenient date. Read the current client notice and verify the intended fork configuration through the project’s release guidance before an operational change. This article has not queried a live testnet node or confirmed activation. A user of another provider’s endpoint should ask that provider about the affected dependency rather than treating a local wallet update as a server upgrade.
Payment Lane reserves capacity for a class of transactions
The primary BEP-703 proposal describes reserved block gas for eligible payments while retaining ordinary pricing and ordering. The default share is 5%, with a governable maximum of 10%. This is not a separate fast lane that guarantees a particular transaction’s inclusion. The proposal’s own document status also should not be confused with proof that its rules are active on the network you use.
Eligibility depends on transaction conditions. The guide says the payment-contract list starts empty, so a stablecoin does not qualify merely because people call it a payment asset. Separate governance listing matters. A nonzero native BNB transfer to an account without code has a different qualification path from a transaction calling a token contract. Providers should test the actual class instead of assigning priority by token ticker.
| Case to check | Relevant question | Unsupported shortcut |
|---|---|---|
| Native BNB transfer | Does it meet the proposal’s bare-transfer conditions? | Every transaction involving BNB must qualify |
| Stablecoin contract call | Is the destination payment contract governance-listed? | Every stablecoin automatically receives reserved capacity |
| Qualified payment | Are normal fees and ordering still satisfied? | Reserved class capacity guarantees this payment’s inclusion |
| General transaction | Which ordinary capacity is available? | Unused reserved payment gas can always be borrowed |
| A mainnet exchange deposit | Has the relevant mainnet stage and service support been confirmed? | A testnet announcement changes the live deposit route |
A client update can change RPC behaviour before the fork
Reth’s release notes flag RPC override compatibility changes that apply immediately after updating, including before Jenner activation. That creates a second testing boundary: the application may encounter a changed client interface before the network enables new protocol rules. Teams should test their authorized simulation and estimation workflows against the actual client version rather than waiting for a fork date to diagnose every change.
The release also distinguishes native CAS20 capability from separate activation for token creation. A standard’s compliance-oriented controls do not establish a token’s legal compliance or availability to a particular account. Likewise, millisecond timestamp access is not an announced increase in block speed, and it does not replace the existing seconds meaning of block.timestamp.
- Identify the network and client, then retain the precise release notice and the action or deadline it states.
- Resolve the applicable schedule through current project guidance before changing a working deployment; keep mainnet and testnet separate.
- Check client-level RPC compatibility as part of the upgrade, independently of later fork activation.
- For payment tests, record the transaction class and contract-list conditions, then verify the network’s actual stage before applying conclusions to live transfers.
What a wallet holder needs to verify
Testnet preparation does not create a reason to send real assets to a test address or a migration account. For a mainnet deposit, follow the receiver’s current asset and network instructions. Payment Lane eligibility, a network fee promotion and a service’s internal crediting process are separate questions; none can be assumed from the word Jenner.
Check supported assets and networks, read how the exchange order works and inspect an available simple swap. KOT.CASH’s pages do not assert Jenner activation, reserved inclusion or a new confirmation deadline. Use the instructions attached to the actual offer.
FAQ
Does BNB testnet Jenner timing establish mainnet activation?
The guide says mainnet timing is announced separately. Keep the network and client notice attached to any date instead of applying a testnet milestone to live deposits.
Does a BNB testnet USDT faucet prove Payment Lane eligibility?
A test token or faucet does not establish governance listing of a payment contract. Verify the proposal’s actual transaction conditions and the relevant network state.
Can a BNB testnet RPC change before Jenner activates?
Reth’s release notes describe compatibility changes that apply when that client is updated. Client behaviour and later network activation are separate testing boundaries.