BNB Chain splits asset power across 4 roles while admins hold the key

BNB Chain’s Jenner testnet release advances a native-asset design that would give a governance-appointed administrator control over when new stablecoins and tokenized assets can be created.

Issuers could have the code available on the network and still need a separate feature switch opened before launching a CAS20 token.

The Oct. 16 v1.8.1 release schedules Jenner for BNB Smart Chain’s Chapel testnet on Oct. 29 at 02:30 UTC. An earlier announcement gives late-November mainnet guidance, with the exact time still unannounced.

The proposed BEP-702 standard remains labeled Draft and covers the new CAS20 token family, while existing BEP-20 tokens would remain unaffected. Its architecture separates three questions: whether the network admits a feature, who can exercise a token’s powers, and which holders those powers may affect.

CAS20 would put common token behavior into native chain logic, implemented as stateful precompiles. The same design gives network governance a role in making the infrastructure available, alongside the issuer’s control over the asset itself.

Under BEP-702, chain governance appoints the activation administrator through GovHub, BSC’s governance forwarding contract. The administrator then makes separate calls to activate or deactivate features.

The release’s activation implementation enforces that division. Only GovHub can change the administrator, and only the stored, nonzero administrator can operate the switches.

The design provides separate switches for creating Asset-variant tokens, creating Stablecoin-variant tokens, and writing to the shared policy registry.

Once a variant is enabled, the factory’s creation path does not contain an individual-issuer approval list. The creator supplies the initial token administrator and initialization instructions. BNB Chain’s issuer-facing early-access whitelist should not be read as proof that this code licenses each issuer separately.

Closing a token-creation feature would stop new CAS20 tokens of that variant from being created. It would not stop an existing token from minting additional units under its own permissions, transferring balances, or administering its roles.

For an issuer planning a launch, the dependency is concrete: installing Jenner support and activating creation for the chosen native-token variant are different milestones. For an existing holder, the same switch is not a direct mechanism for moving or freezing a balance.

The shared policy registry creates a second dependency after a token exists. A token administrator selects policies for specific operations, and each policy has its own administrator responsible for membership.

The tagged policy implementation gates registry writes behind feature activation, including list membership changes and administrator handovers. A token can keep consulting an existing list even when that list cannot be updated.

Consider an account already blocked by a policy used for transfers. If the policy-registry feature is disabled, the list administrator cannot remove the account while that gate is closed. The holder could remain restricted under the existing rule even though the network-level action did not freeze the token or alter its balances.