- BNB Chain’s Jenner testnet release is scheduled for Oct. 29, with mainnet guidance pointing to late November.
- The draft BEP-702 standard would let chain governance control when CAS20 token creation can open, separate from each issuer’s own setup.
- Transfer and seizure rules for CAS20 tokens depend on token-level roles and policies, while existing BEP-20 tokens are not affected.
BNB Chain has advanced its Jenner testnet release, a step toward a native-asset design in which a governance-appointed administrator decides when new stablecoins and tokenized assets can be created. Issuers could have the supporting code available and still be unable to launch a CAS20 token until a separate feature switch is opened. The proposal, BEP-702, remains labeled as a draft.
What Happened
The v1.8.1 release, dated Oct. 16, schedules Jenner for the Chapel testnet on Oct. 29 at 02:30 UTC. An earlier announcement gave late-November guidance for mainnet, but the exact time has not been published.
CAS20 is the new token family covered by BEP-702. It moves common token behavior into native chain logic, implemented as stateful precompiles. Existing BEP-20 tokens would remain unaffected. The proposal separates three questions: whether the network allows a feature, who can exercise a token’s powers, and which holders those powers can touch.
Under the design, chain governance appoints an activation administrator through GovHub, the governance forwarding contract used on BNB Smart Chain. That administrator can separately activate or deactivate three capabilities: creating Asset-variant tokens, creating Stablecoin-variant tokens, and writing to a shared policy registry. Only GovHub can change the administrator, and only the stored, nonzero administrator can operate the switches.
Once a variant is enabled, the factory’s creation path does not check an approved-issuer list. The creator supplies the initial token administrator and initialization instructions. BNB Chain’s early-access whitelist for issuers should not be read as a sign that the code licenses each issuer individually.
Why It Matters
For issuers, the release creates two separate milestones: installing Jenner support and activating creation for the chosen variant. Network readiness alone does not open the door to launches.
For existing holders, the creation switch is not a direct tool for freezing or moving balances. Closing it would stop new CAS20 tokens of that variant from being created. It would not prevent an existing token from minting under its own permissions, transferring balances, or changing its administrative roles.
The shared policy registry adds a second layer. A token administrator selects policies for specific operations, and each policy has its own administrator responsible for membership. Registry writes, including list membership changes and administrator handovers, are gated behind feature activation. A token can keep consulting an existing list even when that list cannot be updated. Because one list can be referenced by several assets, a single membership change may affect an account’s eligibility across every token and operation that uses it.
The source gives a concrete scenario. If an account is already blocked by a transfer policy and the registry feature is disabled, the list administrator cannot remove that account while the gate remains closed. The holder could stay restricted even though the network did not freeze the token or change its balances. Replacing the activation administrator would restore control of the switch, but it would not by itself correct a list entry. Reopening registry writes and updating membership are separate actions.
Market Context
BNB Smart Chain’s BEP-20 standard is the existing token framework on the network, and BEP-702 would add a parallel native family rather than replace it. The approach of building common token behavior into the chain is a design choice that trades one set of concerns for another. Shared native code reduces the need for each issuer to implement the same behavior separately. The proposal also warns that a defect in the native client could affect multiple CAS20 tokens at once and might require another hard fork to fix.
The source notes that Base’s Cobalt controls for its B20 standard use a similar separation of roles and eligibility. CAS20’s distinct element, according to the source, is how network-level feature admission interacts with token-level controls.
Token permissions are split across several roles. Minting, self-burning, seizure, pausing, and unpausing each use separate roles, and these can be assigned to different addresses or concentrated in one. Ordinary transfers check the sender and receiver against their respective policies, and they also check a delegated executor when moving another account’s funds. Minting has its own recipient policy, so being able to receive newly minted units does not automatically permit an account to send tokens.
Seizure is the most sensitive permission. Under the default configuration, a holder is protected through an exemption policy, referred to in the v1.8.1 code as SEIZE_EXEMPT_POLICY. For a seizure to proceed in ordinary post-creation calls, the holder must fail that exemption check, and the operator must hold the seizure role. The seizure function must be unpaused, the holder must have sufficient balance, and the destination must be permitted by the seizure-receiver policy. When these conditions are met, seizeWithMemo bypasses ordinary transfer-policy checks and leaves total supply unchanged. Burning, by contrast, destroys supply and, in ordinary CAS20 calls, only applies to the caller’s own tokens under a separate role. Pausing transfers also does not pause seizure, which has its own pause setting.
What to Watch Next
The Oct. 29 Chapel testnet fork is the next scheduled milestone. Readers should track whether the late-November mainnet guidance receives an exact time, since none has been announced.
Several operational details will matter once the release moves forward:
- Which address will hold the activation administrator role, and how it will sign changes to the switches.
- Which feature switches are opened, and when, for Asset and Stablecoin variants.
- Whether BNB Chain’s early-access issuer program, which describes both variants, expands or changes.
- Whether BEP-702 moves beyond draft status, and whether any native-client defects surface during testing.
For new launches, outcomes will depend on feature admission. For ongoing list maintenance, they will depend on registry availability. For holders, transfer and seizure exposure will depend on the specific permissions and policies each issuer configures.
Source: original report
