BNB Smart Chain (BSC) hat auf seinem Testnet eine neue Mechanik namens Payment Lane aktiviert, die 5 % des Gas-Limits jedes Blocks für qualifizierte Zahlungstransaktionen reserviert. Die Funktion kommt unter BEP-703 als Teil des Jenner-Hardforks, der jetzt auf dem BSC-Testnet live ist, und soll den Zahlungsdatenverkehr vor Überlastung durch allgemeine Netzwerkaktivität schützen.

Händler und Zahlungsdienste sehen sich bei Aktivitätsspitzen häufig mit unvorhersehbarer Transaktionseinschluss gegenüber, und genau dieses Problem zielt die neue Regel an. Für Zahlungsunternehmen ist eine Transaktion, die während einer Überlastungsspitze warten muss, eine verzögerte Abwicklung und keine abstrakte Gebührenfrage — deshalb ist garantierte Blockkapazität zu einem relevanten Designfaktor geworden. Entwickler und Block-Builder können Integrationen nun vor einer möglichen Mainnet-Einführung auf dem Testnet testen.

BNB Smart Chain ist das mit der Ethereum Virtual Machine kompatible Netzwerk von BNB Chain, wobei BNB als nativer Asset zur Zahlung der Gasgebühren dient. Gas ist die Einheit, die den Rechenaufwand von Transaktionen misst, und jeder Block trägt eine maximale Menge davon. Da diese Obergrenze den Blockraum zu einer endlichen Ressource macht, konkurrieren Transaktionen um den Einschluss, sobald die Nachfrage hoch ist — der Zustand, den Payment Lane abmildern soll.

Ankündigung auf X

BNB Chain Developers sagte auf X, dass die Governance-Mechanismen für CAS20 und Payment Lane implementiert und verifiziert wurden. Der Jenner-Hardfork bringt zudem CAS20-Grundlagen und Millisekunden-Zeitstempel auf das BSC-Testnet.

Governance mechanisms for CAS20 and Payment Lane have been implemented and verified. The Jenner hardfork now brings three key updates to BSC testnet: CAS20 functionality: Lays the groundwork for a new Compliant Asset Standard, with tools to manage token transfers, supply,… pic.twitter.com/gNUDLT2KsO

— BNB Chain Developers (@BNBChainDevs) November 1, 2026

Wie Payment Lane Blockkapazität reserviert

Payment Lane funktioniert als Gas-Verrechnungsregel, die während der Blockvalidierung durchgesetzt wird und begrenzt, wie viel Gas allgemeine Transaktionen verbrauchen dürfen. Zahlungs- und allgemeine Transaktionen können weiterhin in beliebiger Reihenfolge innerhalb eines Blocks erscheinen.

Allgemeine Transaktionen können auf das reservierte Gas nicht zugreifen, selbst wenn die Zahlungsnachfrage gering ist. Qualifizierte Zahlungen können dagegen auf die Reservierung zugreifen und weiterhin unter den bestehenden Gebührenregeln um die verbleibende Kapazität konkurrieren. Der 5-%-Anteil legt damit ein Minimum für die Zahlungskapazität fest, ohne eine Obergrenze für die Zahlungsaktivität einzuziehen. Zur Veranschaulichung: Ein Block mit einem Gas-Limit von 100 Millionen würde 5 Millionen Gas für Zahlungen reservieren, sodass 95 Millionen für allgemeine Transaktionen verbleiben.

Diese Boden-ohne-Deckel-Struktur unterscheidet eine Reservierung von einer bloßen Erhöhung des Block-Gas-Limits: Ein höheres Limit erzeugt Kapazität für alle Traffic-Arten gleichzeitig, während eine Reservierung einen Anteil für Zahlungen schützt, egal wie hoch die allgemeine Aktivität wird.

Welche Transaktionen qualifizieren sich

Zwei Wege führen in die Zahlungsklasse. Der erste umfasst Transaktionen, die direkt an einen Contract auf der governance-verwalteten Zahlungsliste gesendet werden. Der zweite umfasst nonzero BNB-Transfers an Konten ohne Code.

Beide Wege erfordern eine Zieladresse und schließen Systemtransaktionen aus. Sie unterstützen die Transaktionstypen 0x00, 0x01 und 0x02. Contract-Erstellung, Blob-Transaktionen und Transaktionen des Typs 0x04 gelten als allgemeiner Datenverkehr.

Bei gelisteten Contracten hängt die Klassifizierung von der Zieladresse ab, unabhängig von der aufgerufenen Funktion. Ein Stablecoin-Transfer, der direkt an einen gelisteten Token-Contract gesendet wird, kann sich qualifizieren, während eine Transaktion an einen nicht gelisteten Router sich nicht qualifiziert, selbst wenn der Router diesen Stablecoin anschließend weiterbewegt. Die Zahlungs-Contract-Liste beginnt leer. Bis die Governance die ersten Contracte hinzufügt, ist der BNB-Transfer-Weg der einzige Pfad in die Zahlungsklasse.

Governance- und Validator-Regeln

Die Governance steuert sowohl die Zahlungs-Contract-Liste als auch die Reservierungsquote, die standardmäßig 5 % beträgt und ein Protokollmaximum von 10 % hat. Nodes lesen die Konfiguration aus dem Zustand des Elternblocks, sodass ein Update die Klassifizierung nicht mitten in einem Block ändern kann.

Block-Builder müssen die Reservierung beim Zusammenstellen von Blöcken berücksichtigen, und Validatoren lehnen jeden Block ab, dessen Gas-Zuteilung die Regel verletzt. Im BEP-675-SendBidBlock-Ablauf erfolgt die Prüfung beim lokalen Import nach der Broadcast, wobei Verstöße über den Builder-Revocation-Mechanismus behandelt werden.

Ungenutztes reserviertes Gas bleibt by Design ungenutzt. Könnten Produzenten es neu zuweisen, könnten sie Blöcke mit allgemeinem Verkehr füllen und Zahlungen vollständig ausschließen.

Die Mechanik garantiert keinen Einschluss, keine festen Gebühren und keine kostenlosen Transfers. Teams können das Testnet nutzen, um Zieladressen, Transaktionstypen und Governance-Listung zu verifizieren, und die Reservierung greift erstmals in dem Block unmittelbar nach der Fork-Aktivierung. Von hier an sind die beobachtbaren Marker Governance-Entscheidungen darüber, welche Contracte in die Zahlungsliste aufgenommen werden, etwaige Anpassungen der Quote innerhalb des 10-%-Protokollmaximums sowie das Testnet-Verhalten vor einer möglichen Mainnet-Einführung.

Berichterstattung via Blockonomi.