At the latest Neo core developer conference, contributors focused on simplifying the proposed custom contract pricing mechanism NEP, evaluating transaction-based approaches to proving node uptime, and preparing governance and cryptographic changes for future releases. This session also provided further clarity on the high-level architecture of Neo N4, which centers on Neo N3 as the main chain with a bridged sidechain.
Custom contract pricing mechanism is filtered to GAS only
Developers have reviewed a draft NEP that introduces a standardized way for smart contracts to define custom execution fees in addition to standard network costs. This proposal uses new pricing metadata fields in the contract ABI, supported by DevPack tools and enforced by Neo VM, to enable models such as pay-as-you-go, subscription-style access, and direct compensation to contract holders.
Discussion focused on reducing complexity by limiting the first version of the mechanism to GAS-only payments. Restricting the design to GAS is considered a significant simplification compared to supporting any NEP-17 token, while addressing the core need of contract-level toll collection.
We were also interested in a more streamlined design where a portion of existing system charges were redirected to contracted or designated beneficiaries via dedicated interoperable calls. This avoids introducing a rich asset model in the initial release and relies only on the GAS already present on the VM during transaction execution.
More advanced concepts, such as paying execution fees in other tokens via native liquidity pool agreements, were recognized as having value in the long term, but were considered outside the scope of the current NEP. The priority is to complete a clean GAS-only mechanism that can be extended later without breaking compatibility or unduly complicating the initial implementation.
The NEP will be updated to reflect this direction, incorporating feedback from recent reviews and simplifying the specification accordingly.
Node liveness proof has moved to a transaction-based model
The group continued to work on designing a “proof-of-node” mechanism to ensure that registered committee members are running live, correctly configured nodes.
Previous ideas, such as relying on lightweight proof-of-work or peer-to-peer extensible messages, raised concerns about network spam and ambiguity in distinguishing connectivity issues from actual downtime. Currently, the preferred direction is an on-chain approach where the activeness of the committee is demonstrated through regular transactions.
This model requires committee members to submit small transactions at defined intervals. Responsibility for each active transaction can be assigned deterministically based on data such as previous block hashes, and the dBFT plugin can handle transaction creation automatically. This ensures that only properly running nodes can meet the requirements without manual intervention.
A dedicated governance-oriented native contract can maintain a record of these pings, including the date and time each committee member last sent a liveness transaction, and aggregate success metrics over time. Compared to P2P layer messages, this design provides clearer auditability, natural rate limiting through transaction fees, and fewer changes to network-level permissions.
Details such as timing windows, penalties for failed pings, and integration with future candidate selection logic will be refined in follow-up work, but extensive adjustments were made to the use of transactions as the basis for node liveness tracking.
Blocked funds recovery targeting Neo 3.9
The developer is Request blocked funds The pull request is still under discussion and is a candidate feature for inclusion in the Neo 3.9 release.
This change adds a controlled recovery mechanism for addresses frozen due to governance measures, such as after hacking or malicious use of funds. After the one-year period, blocked balances cannot be moved without the approval of 19 of the 21 commissioners, ensuring that any recovery efforts require a strong supermajority.
This feature is clearly not designed for lost-key scenarios where users can no longer prove ownership. Instead, we aim to formalize a narrow path for handling authorized addresses under strict time and signature constraints, improving clarity and predictability for ecosystem stakeholders.
Ethereum compatible BLS interface evolves via neo-go
The conference also touched on ongoing work to support Ethereum-compatible serialization of BLS12-381 in CryptoLib native contracts, primarily for Neo X and EVM-adjacent use cases.
neo-go pull requests now implement the desired interface, reflecting a prior agreement that CryptoLib’s Ethereum-compatible methods should align with the existing API design rather than introducing a separate byte-only style. Review feedback from the Neo X team has already been incorporated, and additional reviews are requested to finalize the interface.
The same approach will be ported to the C# implementation once the neo-go version is deemed stable. It is hoped that this pattern can later be extended to other curves such as BN254, maintaining interoperability with EVM tools while maintaining a consistent cross-platform cryptographic interface.
N4 architecture: N3 main chain with native bridge sidechain
To conclude the meeting, developers discussed how the evolving Neo N4 roadmap relates to the current Neo N3 network and future bridge construction.
Neo N4 is positioned as an architecture where Neo N3 continues to operate as the main chain, with no changes or user migration required for existing dApps. Compatibility between N4 and N3 was emphasized. Application-specific sidechains run Neo N4 code (developed on the master branch) and connect back to the main chain through a native smart contract-based bridge that handles cross-chain communication and asset movement.
The core development team was asked to consider multiple native bridge designs that fit this model, including the possibility of incorporating or adapting existing solutions such as the AxLabs bridge. Once several options are documented, Neo leadership selects the approach that best meets N4’s long-term scalability and interoperability goals.
This direction strengthens Neo N3 as a stable and compatible base layer while providing a clear path to expanding the ecosystem through specialized sidechains and standardized cross-chain infrastructure.
The full text of the discussion can be viewed at the link below.
https://youtu.be/96kpFwQe9EA
