Neo Core developers finalize v3.9 scope, advance testing and CryptoLib design work

In the most recent Neo Core call, developers advanced testing for execution fee and whitelist changes, refined plans for Ethereum-compatible BLS support in the CryptoLib native contract, and evaluated a new governance mechanism for handling blocked funds. The meeting also explored options to ensure validator candidates operate real nodes, including staking- and slashing-based designs.

Ensuring validator candidates operate real nodes

Developers opened with discussion on how to prove that Council candidates operate functional nodes, a requirement on the path to flattening GAS rewards. Two broad approaches are under consideration: a lightweight proof-of-work scheme for candidates, and a staking and slashing model in which candidates lock NEO and can be penalized if they fail liveness checks within a set timeframe.

Because consensus nodes already expose liveness via view change behavior, the new mechanisms are intended for candidate verification. Further design details will be refined in the corresponding issue.

Progress toward Neo v3.9.0

Developers agreed that the v3.9.0 branch is nearly complete. A proposal to include arbitrary message signing support ported from Flamingo was discussed. Because the functionality depends on an additional pull request and a clear specification for signed message semantics, it may be scheduled for a later release if documentation is not finalized in time.

One item, NEP-25, will not ship in v3.9.0. Planned changes to the standard are expected to push development back by one to two months, so contributors agreed to defer it to avoid delaying the release.

Testing merged changes: execution fees and whitelist

Execution fee factor changes and whitelist-based free transaction support have already been merged for v3.9.0. A dedicated issue will define a test checklist for these features before the final binaries are published.

Broader review from multiple contributors was encouraged, particularly for pull requests that touch protocol-level behavior. The intent is to reduce the risk of divergent behavior across explorers, wallets, and alternative node implementations once the update is deployed.

Rethinking Ethereum-compatible BLS support in CryptoLib

Developers also examined the proposal to add Ethereum-compatible aliases for BLS12-381 in the CryptoLib native contract.

Two main concerns were identified. New methods operate on byte arrays, whereas existing CryptoLib functionality exposes BLS points through interop interfaces with dedicated serialization helpers. Repeated serialization and deserialization for each operation is inefficient and inconsistent with current API design.

The preferred direction is to align Ethereum-compatible BLS support with the established interface style by adding serialization methods for the Ethereum format while executing operations on internal BLS point representations. Compatibility with Ethereum’s serialization format is the main requirement, not a mirrored API surface. Implementation details will be refined across both the C# node and neo-go to ensure consistent behavior.

Governance tool for blocked funds

The group also reviewed a governance change that would allow the Neo Council to move funds out of blocked accounts after a defined period, requiring 19 of 21 signatures.

The mechanism is intended for cases where funds are frozen in malicious or compromised wallets. It is not intended to recover assets for users who have lost private keys and cannot prove ownership.

A vote will determine the default blocking period, with options such as six months, one year, or two years. Once finalized, the feature is expected to provide a clearer process for handling sanctioned addresses.