neonewstoday.com
In the latest Neo core developer meeting, contributors focused on simplifying the proposed custom contract fee mechanism NEP, evaluating a transaction-based approach for proving node liveness, and preparing governance and cryptography changes for upcoming releases. The session also brought additional clarity to the high-level architecture for Neo N4, centered on Neo N3 as the main chain with bridged sidechains.
Custom contract fee mechanism narrows to GAS-only
Developers revisited the draft NEP that introduces a standardized way for smart contracts to define custom execution fees on top of standard network costs. The proposal uses a new fee metadata field in the contract ABI, backed by DevPack tooling and enforced by the Neo VM, enabling models such as pay-per-use, subscription-style access, and direct compensation for contract maintainers.
Discussion focused on reducing complexity by limiting the first version of the mechanism to GAS-only payments. Restricting the design to GAS was seen as a significant simplification compared to supporting arbitrary NEP-17 tokens, while still addressing the core need for contract-level fee collection.
There was also interest in an even more streamlined design where a portion of the existing system fee is redirected to the contract or a designated beneficiary via a dedicated interop call. This would avoid introducing a rich asset model in the initial release and rely solely on GAS already present in the VM during transaction execution.
More advanced concepts -such as paying execution fees in other tokens via native liquidity pool contracts – were acknowledged as valuable for the longer term but considered out of scope for the current NEP. The priority is to finalize a clean, GAS-only mechanism that can later be extended without breaking compatibility or overcomplicating the initial implementation.
The NEP will be updated to reflect this direction, incorporating recent review feedback and simplifying the specification accordingly.
Node liveness proofs move toward a transaction-based model
The group continued design work on a “proof of node” mechanism to ensure that registered committee members operate live, correctly configured nodes.
Earlier ideas such as lightweight proof-of-work or relying on peer-to-peer extensible messages raised concerns about network spam and ambiguity in distinguishing connectivity issues from actual downtime. The preferred direction is now an on-chain approach where committee liveness is demonstrated via periodic transactions.
Under this model, committee members would be required to send a small transaction at defined intervals. Responsibility for each liveness transaction could be assigned deterministically based on data such as the previous block hash, and the dBFT plugin could handle transaction creation automatically. This ensures that only properly running nodes can satisfy the requirement without manual intervention.
A dedicated governance-oriented native contract could maintain a record of these pings, including when each committee member last sent a liveness transaction and aggregate success metrics over time. Compared to P2P-layer messages, this design offers clearer auditability, natural rate limiting via transaction fees, and fewer changes to network-level permissions.
Details such as timing windows, penalties for missed pings, and integration with future candidate-selection logic will be refined in follow-up work, but there was broad alignment around using transactions as the foundation for node liveness tracking.
Blocked funds recovery targeted for Neo 3.9
Developers were reminded to review the Request blocked funds pull request, which is still under discussion and a candidate feature for inclusion in the Neo 3.9 release.
The change would add a controlled recovery mechanism for addresses that have been frozen by governance actions, such as after a hack or malicious use of funds. Once a one-year period has passed, blocked balances could be moved only with the approval of 19 out of 21 committee members, ensuring that any recovery operation requires a strong supermajority.
The feature is explicitly not designed for lost-key scenarios where users can no longer prove ownership. Instead, it aims to formalize a narrow path for handling sanctioned addresses under strict time and signature constraints, improving clarity and predictability for ecosystem stakeholders.
Ethereum-compatible BLS interface progresses via neo-go
The meeting also touched on ongoing work to support Ethereum-compatible serialization for BLS12-381 in the CryptoLib native contract, primarily for Neo X and EVM-adjacent use cases.
A neo-go pull request now implements the desired interface, reflecting prior agreement that CryptoLib’s Ethereum-compatible methods should still 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 have been requested to finalize the interface.
Once the neo-go version is considered stable, the same approach will be ported to the C# implementation. The expectation is that this pattern can later be extended to other curves such as BN254, preserving a consistent cross-platform cryptographic interface while maintaining interoperability with EVM tooling.
N4 architecture: N3 main chain with native-bridge sidechains
To close the meeting, developers discussed how the evolving Neo N4 roadmap relates to the current Neo N3 network and upcoming bridge work.
Neo N4 is being positioned as an architecture where Neo N3 continues to operate as the main chain, with no required changes for existing dApps and no migration required for users. Compatibility between N4 and N3 was emphasized. Application-specific sidechains will run Neo N4 code (developed on the master branch) and connect back to the main chain through native smart contract–based bridges that handle cross-chain communication and asset movement.
The core development team has been asked to explore 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 will select the approach that best fits N4’s long-term scalability and interoperability goals.
This direction reinforces Neo N3 as a stable, compatible base layer while providing a clear path to expand the ecosystem through specialized sidechains and standardized cross-chain infrastructure.
The full discussion can be found at the below link:
https://youtu.be/96kpFwQe9EA