This article explores a key aspect of this dynamic: decentralisation in updating protocols. Who decides on changes? Who executes them? How quickly can they be applied?
Through concrete cases, we will see how these choices influence the governance, security and resilience of projects. Between radical immutability, hybrid models and disguised centralisation, where does a protocol really stand on the decentralisation scale?
What decentralisation is - and what it is not In the cryptocurrency world, decentralisation is often presented as an absolute ideal: reducing dependence on central authorities in favour of distributed decision-making and transactions between network players. In practice, however, an entirely decentralised protocol is rare. Decentralisation works more like a spectrum, on which projects position themselves to varying degrees.
This spectrum applies to almost every aspect of a protocol: governance, distribution of nodes and validators, external data sources, cash management, hosting, token distribution... The list goes on and on (as Vitalik Buterin explains) .
This article looks at a key aspect: decentralization in protocol updating. Using recent examples, we will analyse the approaches that work and those that pose problems. Design choices in update governance influence the balance between security, flexibility and user protection.
What are the determining factors? What trade-offs do they involve? How can we assess a protocol's true degree of decentralisation? These are all crucial questions for understanding where a project really stands on the decentralisation spectrum.
Protocol immutability: one extreme of the spectrum Bitcoin is often described as an immutable protocol. However, its code can be modified - but only at the price of a broad and structuring consensus. Any changes to the network rules must be validated by miners, node operators and developers. Unlike protocols governed by on-chain governance, where changes can be adopted via votes, Bitcoin's evolution relies on two distinct mechanisms: soft forks (backward-compatible modifications) and hard forks (non-backward-compatible modifications).
This slow and rigorous evolution process is not a flaw, but an essential feature of the protocol. Bitcoin's immutability does not mean that it is technically unalterable, but that it is designed to resist arbitrary changes or changes imposed by a single entity. Its consensus mechanism and the strength of its community ensure that no stakeholder can change its fundamental rules-such as the 21 million BTC cap-without massive support.
This model represents one end of the upgrade spectrum: it favours security and resilience in the face of change, at the expense of flexibility.
A hybrid approach Many protocols take a hybrid approach to updates, seeking to balance speed of innovation with security. This strategy is based on a balance between centralised supervision and decentralised mechanisms. Yet achieving a high level of decentralisation remains a major challenge.
L2Beat data bears this out: of the 59 rollups evaluated, only three reached "Stage 2" decentralisation , the most advanced level. Incidentally, these three protocols (DeGate, ZkMoney and Fuel) account for just 0.1% of the total value locked (TVL) on Layer 2. What's more, they are only Appchains, i.e. they have been designed to run a single application. To date, no general-purpose L2 is above Stage 1 (Arbitrum, Optimism and Ink).
This figure highlights a striking reality: truly decentralised governance of updates remains the exception rather than the norm.
The decentralisation of a protocol in terms of scalability hinges on three fundamental questions: who decides on changes? Who applies them? And how quickly can they be implemented? Each of these elements reveals the degree of control exercised by a restricted group or, on the contrary, its distribution within the network.
👉 Who decides on changes? At one end of the spectrum, a fully centralised protocol relies on its founding team or foundation to propose and implement all updates, without consulting the community. Many fledgling projects adopt this approach to evolve quickly, but it creates a single point of failure.
A more hybrid approach incorporates governance mechanisms such as token voting or DAOs (decentralised autonomous organisations). However, in practice, key contributors often retain a dominant influence, notably through high proposal thresholds or a delegated voting system.
In a fully decentralised system, any member of the community can propose changes, and updates must obtain a broad on-chain consensus. This approach reduces dependency on privileged actors and strengthens the resilience of the protocol to arbitrary decisions.
👉 Who executes changes? Once a decision is made, the way it is implemented determines the degree of dependency of the protocol on trusted intermediaries.
In a centralised model, a small team or multi-sig portfolio can apply updates directly, giving them unilateral control over the evolution of the protocol.
A hybrid system relies on governance votes to approve changes, but their execution remains in the hands of a dedicated team, who must apply them manually.
Finally, in the most decentralised model, all human intervention is removed: updates are integrated directly into autonomous smart contracts, ensuring that governance decisions are executed exactly as approved, with no possibility of manipulation or delay.
👉 How quickly can changes be applied? The speed with which updates can be applied plays a key role in balancing adaptability and security.
In a fully centralised system, changes can be applied instantly, enabling rapid response but also increasing the risk of rug pulls or hostile takeovers via governance.
A hybrid approach often incorporates timelocks, imposing a delay between approval and execution of updates. This mechanism gives users the time they need to react to forthcoming changes.
At the more decentralised end of the spectrum, changes take much longer to implement, or may not be possible at all. Some protocols are immutable, with their smart contracts unable to be updated after deployment.
Timelocks are particularly crucial in highly governed protocols, as they act as a safety net even when other aspects of the update process remain centralised. Although the execution of changes still rests with key contributors, these timelocks allow users to anticipate, evaluate and, if necessary, exit the protocol before changes take effect.
Is decentralisation always preferable? Decentralisation is often presented as an intrinsic improvement over centralisation, but the reality is more nuanced. The very characteristics that make a decentralised protocol immutable or time-locked code, distributed governance, enforcement of rules on the blockchain-can also inhibit adaptability and rapid innovation.
The two leading smart contract blockchains, Ethereum and Solana, illustrate this dilemma well.
Ethereum favours a structured and largely decentralised update process, relying on community consensus and transparency. This model reflects its vision of a network that is neutral and resistant to censorship: evolutions are lengthy and deliberative, making it virtually impossible to disrupt the network or block transactions.
>> Read the fundamental analysis of Ethereum
Solana, by contrast, adopts a more centralised approach, with a heavy reliance on core contributors and a smaller number of validators. This structure ensures greater responsiveness in the event of a technical problem. In the event of a crisis, the central team can quickly coordinate the network players to suspend activity, correct critical faults and orchestrate a restart. But this rapid response capability comes with an increased risk of centralised control and censorship.
>> Read the fundamental analysis of Solana
This is why protocols in the launch phase are generally more centralised than mature projects. In their early stages, they need to be flexible in order to experiment, fix bugs and adjust their trajectory quickly-which mechanisms like timelocks can get in the way. They are also more vulnerable to security risks, prompting them to retain emergency controls, such as pause functions or scalable contracts, to quickly correct any flaws. Finally, decentralised governance requires a strong and committed community, something that is often absent in the early stages of development.
As a protocol matures, it is better equipped to decentralise. A product that has found its market, proven smart contracts and active community participation make governance more viable-provided the founding team is genuinely willing to cede control.
Many projects advertise decentralisation as a long-term goal, but these promises need to be critically scrutinised. In some cases, they appear to be more marketing than a genuine commitment. Some teams announce a transition to decentralisation, but retain crucial decision-making power when major choices have to be made. The tensions around the governance of SushiSwap and Arbitrum are striking examples of this.
Case studies Tensions surrounding the decentralisation of protocols often arise from a mismatch between users' expectations and the reality of how the project works. While all protocols fall somewhere on the decentralisation spectrum, some are far more transparent than others about their true level of autonomy.
👉 Aave: a model of decentralisation and transparency Aave stands out for its entirely on-chain governance, ensuring that no centralised entity can unilaterally impose updates. AAVE token holders propose and vote on changes, ensuring that decisions remain in the hands of the community. Unlike many projects that retain administration keys, Aave has switched completely to a DAO model, removing any possibility of arbitrary intervention by the founding teams.
Beyond governance, Aave puts safeguards in place to protect its users. Any update to the protocol is subject to a timelock, a delay before the change is actually applied. This allows users to anticipate and, if necessary, withdraw their funds before a change takes effect. This approach reduces the risk of hasty or malicious updates, reinforcing the protocol's commitment to decentralisation.
>> Uniswap, Aave, Sky: What strategies for the "OGs of the DeFi"?
👉 Usual Money: the risks of hybrid governance Inversely, the recent affair surrounding Usual Money illustrates the dangers of ill-defined governance. At the beginning of January, the team abruptly changed the redemption mechanics of its USD0++ stablecoin, taking users by surprise who considered the protocol to be more decentralised than it really was.
In contrast to Aave, where decisions are made publicly, Usual Money made these changes in the shadows, without prior consultation or a vote by the DAO. The problem was compounded by the centralisation of administration keys: with no timelocks or community control, the team was able to implement these changes unilaterally and discreetly.
The result: panic and mistrust. Users and investors realised too late that they had little control over the protocol they thought was decentralised. In just a few days, the project's TVL plummeted by 40%, revealing a deep malaise within the community.
Even though the Usual Labs team claims to have acted with transparency and good intentions , the reaction of users and the ensuing loss of trust show the importance of clear communication in the governance of DeFi protocols. The project's TVL has since fallen by 47%. If projects promise a democratised financial model, they must also take responsibility for clearly informing their users about the inherent risks.
👉 Decentralisation or the illusion of decentralisation? Even Aave, despite its commitment to community governance, remains highly concentrated: more than 70% of the total supply of tokens is held by just over 120 wallets.
This example illustrates a common paradox in the ecosystem: the stated decentralisation can mask a real concentration of power. Without transparency and strong safeguards, "hybrid decentralisation" quickly runs the risk of becoming an act, where control remains in the hands of a small group despite a democratic appearance.
Tools for assessing decentralisation Faced with the tendency of protocols to embellish their level of decentralisation, it is essential that users and investors examine these claims critically. Many projects present themselves as "community-governed" or "trustless", but the reality is often quite different. Fortunately, several independent tools provide an objective analysis of a protocol's degree of governance, scalability and actual decentralisation:
- DeFi Scan - A comprehensive tool for analysing decentralisation metrics, governance structures and risks associated with smart contracts in DeFi protocols.
- L2Beat - Specialising in the evaluation of Layer 2 solutions, this tool examines their level of decentralisation, scalability and security.
- Tally - A platform dedicated to governance transparency, which tracks proposals and voting dynamics within DAOs in real time.
By combining these resources, users can better understand where a protocol really stands on the decentralisation spectrum and avoid falling into the trap of misleading marketing.
The limitations of the tools and the importance of independent analysis Newer or smaller projects-such as Usual Money-are not always included in these tools, making independent analysis essential. When it comes to assessing the decentralisation of a protocol, several signals can reveal hidden centralisation:
- Opaque governance, with no clear details on decision-making.
- Administration keys with unilateral control, allowing a small team to modify the protocol without consultation.
- Frequent and unpredictable changes, applied without community validation.
If a project remains evasive about its governance mechanisms or who really holds control, this is a warning sign to be taken seriously-both for users and investors.
Decentralisation is a process, not a binary state Protocols in the launch phase often rely on temporary centralisation to gain agility, security and speed of development. Most users and investors accept this compromise, attracted by the innovative potential of emerging projects. This flexibility can be beneficial for the ecosystem, provided it is announced transparently and teams do not abuse it (as with Usual).
What is really damaging the crypto industry is the distortion of the concept of decentralisation. Sometimes this confusion is unintentional, due to a lack of clarity in communication. Other times, it's intentional deception. In either case, misplaced trust can expose users to unforeseen risks, governance failures and financial losses.
Evaluating the degree of decentralisation of a protocol is essential to managing risk. In an industry where control mechanisms vary considerably, rigorous due diligence allows informed choices to be made and avoids the pitfalls of disguised centralisation.
