EIP-2535 PoC

[Proposal] Full On-Chain Governance with Upgradeable Modules (EIP-2535 PoC)

This issue presents a proof-of-concept for a fully on-chain governance system in which protocol upgrades can be proposed, voted on, and executed entirely within the blockchain, without any reliance on off-chain coordination.

While the demo is implemented in Solidity for accessibility, production deployments should target Rust compiled to WASM for stronger security guarantees, higher performance, and greater architectural flexibility.

Motivation

Governance is often the weakest link in decentralized systems — frequently concentrated in single admin keys or multisigs, or dependent on off-chain voting mechanisms.
This proposal demonstrates that a self-upgrading, fully on-chain governance process is achievable by leveraging a modular smart contract architecture inspired by the EIP-2535 Diamond Standard.

Why Rust/WASM for Production?

Rust compiled to WASM offers significant advantages over Solidity for production smart contracts. Its memory and type safety reduce common vulnerabilities, providing stronger security guarantees. Performance-wise, Rust/WASM enables deterministic execution with substantially higher throughput compared to the EVM. Additionally, Rust benefits from a mature compiler ecosystem, comprehensive linting tools, and more robust upgrade workflows, making it an ideal choice for secure and efficient on-chain governance.

Smart contract execution models have changed for on-chain governance. Polkadot’s upcoming JAM (Join-Accumulate Machine) upgrade promises execution at approximately 40% of native hardware speed—a significant improvement over traditional EVM throughput—making complex governance logic more feasible. Meanwhile, platforms like Stellar and Solana offer high throughput environments capable of supporting on-chain governance, though often at the cost of some decentralization. Polkadot parachains further enhance this space by providing a WASM-first environment with customizable runtimes, shared security, and upgrade patterns uniquely suited for robust, decentralized governance systems.

PoC Components

The PoC includes several key components. At its core is the Diamond Proxy (EIP-2535), a minimal proxy written in Yul that routes calls to the appropriate facets. The GovernanceFacet handles the essential governance functions such as proposal submission, voting mechanics, quorum and diversity enforcement, and delayed execution of approved upgrades. An AliasFacet is included as a placeholder for managing identity mappings and permissions. A fallback dispatcher ensures that all function calls are correctly routed to their corresponding facets based on function selectors.

The governance system supports advanced features to ensure robust decision-making. Voting power can be weighted by Autonomous Systems (AS) or organizations, allowing for granular influence distribution. Quorum checks ensure not only that enough votes are cast but also that there is sufficient diversity among participants to prevent centralization. Upgrade proposals specify details such as the address of the new facet, which function selectors should be added or replaced, and a version hash that links to an external audit for transparency. Finally, a time delay between the successful vote and upgrade execution adds an extra layer of security and accountability.

Security & Design Caveats

The demo is implemented in Solidity/EVM for accessibility and ease of demonstration, but this is not the recommended production stack. For real-world deployments, Rust targeting WASM runtimes such as Substrate or CosmWasm is preferred due to improved safety and performance.

The Diamond storage layout requires careful design to prevent collisions between facets, ensuring data integrity across upgrades. Although the PoC currently requires proxy-owner privileges to execute upgrades, this process can be fully automated and governed on-chain through carefully defined governance rules.

Finally, adversarial testing is critical. The system must be robust against spam proposals, vote manipulation, and quorum gaming to maintain a fair and secure governance process.

Why This Matters

Most existing governance models either depend heavily on off-chain coordination with multisig approvals or rely on on-chain processes controlled by a small group of privileged admins. This creates centralization risks and weakens trust in the system. By contrast, a fully on-chain, self-executing governance framework ensures that all protocol upgrades and decisions are governed transparently and automatically by the rules encoded within the system itself. This eliminates single points of failure, dramatically reduces the attack surface for governance capture or censorship, and empowers the community to control their own protocol evolution without intermediaries. With recent breakthroughs in WASM execution—such as Polkadot’s JAM upgrade delivering near-native speeds—these secure, scalable, and trustless governance models are no longer theoretical but practical.

Final Suggestions

I believe the Governance, Naming & Trust, Payment System, Governance & Versioning layers should entirely be based onchain together with their logic, and the offchain side of the network can rely on onchain state as a source of truth and transparency. Furthermore, I believe the network should own its own form of value, together with strong tokenomics and planning, which could enable better algorithmic incentives mechanisms (ie. increase rewards when not enough nodes are operational, and reduce rewards when demand is satisfied or saturated)