On January 15, 2026, Aave’s developers disclosed an unusual problem with a major protocol upgrade. Governance had approved the move to version 3.6, but some of the contracts scheduled to carry out the change were no longer eligible for execution.
The problem was not a rejected vote or a newly discovered vulnerability. Seven network deployments had upgrade payloads that were approaching a built-in expiration limit. Those payloads had been registered in late 2025, and the governance system would not allow them to execute after 30 days.
Ethereum’s Core and Prime markets could proceed. The remaining deployments needed another proposal.
For users, the incident was not reported as a loss of funds. It revealed something more fundamental about decentralized finance: even after a governance decision has been made, the ability to change a live protocol depends on a separate network of contracts, permissions, and execution conditions.
Those permissions are important long before anything goes wrong.
When someone deposits USDC into a lending protocol, the transaction establishes a position under the rules enforced by its smart contracts. But in an upgradeable system, those rules may change over the lifetime of the deposit.
A future implementation could change borrowing conditions, risk calculations, or how certain operations behave. Emergency permissions might also determine whether the user can withdraw during a security incident.
The assets are held by smart contracts. The authority to change how those contracts operate is a separate issue.
The Smart Contract Address Can Stay the Same While Its Rules Change
Blockchain immutability is often misunderstood as a guarantee that every application deployed on a blockchain must continue operating according to its original code.
Ethereum does not allow someone to arbitrarily rewrite the bytecode of an existing contract. Yet developers can design applications that separate the address users interact with from the code responsible for executing their transactions.
One common approach is an upgradeable proxy.
As explained in OpenZeppelin’s proxy architecture documentation, a proxy delegates calls to an implementation contract. The proxy retains the application’s storage, while the implementation provides the logic for reading or modifying that storage.
Consider a lending market where users deposit tokens through a proxy address.
The proxy records information about deposits, borrowing positions, and other account states. When a user requests a withdrawal, the transaction is executed according to the implementation currently connected to that proxy.
An authorized upgrade can redirect the proxy to a different implementation.
The user’s deposit does not need to be transferred into a newly created market for this to happen. The contract address can remain unchanged, along with the balances stored under it, while future interactions are processed by different code.
Some DeFi protocols do not use this design, and some parts of an upgradeable protocol cannot be changed without restrictions.
The important distinction is between the permanence of an address and the permanence of the rules enforced through it.
For an ordinary depositor, a familiar contract address may provide continuity without guaranteeing that the underlying implementation has remained identical.
Compound III makes this relationship especially visible.
In its official governance documentation, Compound explains that when governance changes certain immutable configuration parameters, a new Comet implementation must be deployed. Once the proposal is approved and executed, the market’s proxy points to that new implementation.
The market remains accessible through its established proxy address.
What changes is the implementation governing its behavior.
This is not inherently a weakness. Upgradeability allows protocols to address vulnerabilities, improve efficiency, introduce features, and respond to changing market conditions without forcing every user to migrate manually.
But it also creates an enduring dependency: someone, or some authorized combination of participants and contracts, must retain the power to approve and execute those changes.
Aave and Compound Put Different Clocks on Governance
A governance vote is one form of authorization. A timelock is another form of protection.
Rather than allowing a successful proposal to execute immediately, a timelock requires a minimum waiting period before the approved action can take effect.
That interval can give users, developers, security researchers, and other stakeholders time to examine what is about to change.
Aave and Compound both use governance delays, but their documented standard processes have different timelines.
Under Aave’s governance voting rules, a typical Short Executor proposal has a one-day delay before voting, followed by three days of voting and a one-day execution timelock.
Compound’s governance documentation describes a two-day review period, three days of voting, and a two-day timelock.
Using those stated durations, Ravel calculates the following baseline comparison.
| Governance stage | Aave Short Executor | Compound standard process |
|---|---|---|
| Pre-vote waiting period | 1 day | 2 days |
| Voting period | 3 days | 3 days |
| Post-vote timelock | 1 day | 2 days |
| Total baseline | 5 days | 7 days |
The calculation is straightforward: one plus three plus one gives Aave’s five-day baseline, while two plus three plus two gives Compound’s seven days.
These are procedural baselines, not a measurement of individual proposal execution times. Queueing, cross-chain message delivery, automation, transaction timing, and additional governance steps can extend the actual interval. Aave also uses longer voting and timelock periods for proposals involving core governance permissions.
Nor should the comparison be interpreted as proof that a seven-day process is necessarily safer than a five-day process.
The quality of the proposed code, its review, the concentration of voting power, and the permissions available outside the standard governance process may matter more than an additional waiting day.
A timelock is valuable because it makes an authorized change observable before execution.
It does not make the change optional for users who already have funds in the protocol.
If the proposal passes and executes, the new rules can apply to existing positions.
Aave’s January 2026 Upgrade Shows What Approval Does Not Guarantee
Aave’s version 3.6 rollout offers a documented example of the distinction between approving an upgrade and successfully implementing it.
The upgrade introduced several changes, including more flexible efficiency-mode configurations and adjustments to how received aTokens are automatically treated as collateral.
According to BGD Labs’ official upgrade discussion, the deployment was divided into stages rather than applied simultaneously to every market.
The first proposal was submitted on January 3, 2026. It covered nine deployments across smaller markets, including Scroll, Optimism, Gnosis, Sonic, and other networks.
BGD reported on January 9 that the first group had been successfully upgraded.
The second proposal followed on January 11, targeting larger deployments that included Ethereum Core, Ethereum Prime, Base, Arbitrum, Avalanche, and several others.
Its planned execution date was January 16.
Then came the complication.
On January 15, BGD explained that the non-Ethereum payloads associated with the second proposal had been registered near the end of 2025. By the intended execution date, they would exceed the governance infrastructure’s 30-day payload expiration window.
Even though governance had approved the upgrade, those payloads could not execute.
The Ethereum Core and Prime payloads remained valid and were executed on January 16. Seven other network deployments needed a fresh proposal.
BGD submitted that third proposal on the same day, targeting execution later in January.
The published record establishes the following sequence:
| Date | Documented development |
|---|---|
| January 3 | First upgrade proposal submitted |
| January 9 | First group confirmed successfully upgraded |
| January 11 | Second proposal submitted |
| January 15 | Seven non-Ethereum payloads identified as affected by expiry |
| January 16 | Ethereum Core and Prime upgrades confirmed executed; third proposal submitted |
The second proposal’s Ethereum execution was confirmed five calendar days after its January 11 submission. That calendar-day difference does not establish the precise elapsed time between its on-chain creation and execution transactions.
The seven other deployments were expected to follow several days later, rather than being upgraded under the original payloads.
This information was not evidence of a successful malicious upgrade, nor of user funds being exposed to a newly discovered exploit.
It was an execution-control mechanism working as designed.
Still, it reveals why governance analysis cannot stop at the vote result.
A proposal may be approved while the associated execution payload is expired, incompatible, incorrectly configured, or otherwise unable to run.
Aave’s architecture prevented the affected payloads from being executed. The same event also demonstrated that governance approval was insufficient to deliver the change without additional operational work.
For depositors, these details determine when the protocol they use actually begins running under new rules.
Compound’s Upgrade Mechanism Has More Than One Permission Layer
Compound III provides another way to examine the question of control.
Its markets, known as Comets, use a collection of contracts to manage configuration and implementation upgrades.
The Configurator stores parameters used to construct a Comet implementation. The Comet factory can deploy an implementation using that configuration, and the proxy administration mechanism can connect the market’s proxy to it.
A governance proposal can modify the relevant configuration and trigger the replacement.
The change happens without requiring users to move their positions to a different proxy address.
But the exact permission model deserves closer attention.
In the Compound repository’s CometProxyAdmin source code, the deployAndUpgradeTo function is protected by a modifier named ownerOrMarketAdmin.
Instead of permitting only the contract owner, the modifier also supports callers who pass a check through a MarketAdminPermissionChecker contract.
The distinction is significant.
The documented architecture centers on governance and the Timelock as the authority over Compound III markets. Yet the repository code contains a mechanism through which appropriately authorized market administrators can also participate in upgrade operations.
The Configurator source code similarly includes governorOrMarketAdmin access checks for selected configuration functions, including some interest-rate and collateral-related parameters.
That does not establish that an arbitrary market administrator can change every Compound deployment.
Whether the additional path is enabled, who can use it, and which restrictions apply depend on the contracts and permission-checker configuration actually deployed for a particular market.
Reviewing the repository source code is therefore not a substitute for inspecting the corresponding on-chain contracts.
Nevertheless, this is a useful example of why the answer to who controls a protocol can be more complicated than simply identifying its governance token.
The governance process may authorize administrative roles, which in turn can execute certain changes within specified limits.
That delegation can improve operational responsiveness. It can also make the effective permission structure less obvious to someone who only reads the public voting rules.
The relevant question becomes not only whether COMP holders control governance, but what powers governance has delegated and under which conditions those powers can be exercised.
A Timelock Does Not Guarantee That Users Can Withdraw Before a Change
The usual defense of upgradeable DeFi is that users receive advance notice.
A proposal is published, voting takes place, a timelock begins, and depositors can decide whether to remain exposed to the new rules.
In principle, this procedure is an important protection.
In practice, the user’s ability to exit determines the outcome.
Compound III’s emergency controls demonstrate the limitation.
The protocol includes a Pause Guardian role designed to respond to security threats. The guardian is distinct from the ordinary voting process and has authority over specific operations.
The Comet implementation source code exposes a pause function that can be called by the configured governor or Pause Guardian.
The function accepts separate controls for supply, transfers, withdrawals, liquidations through the absorb mechanism, and collateral purchases.
Most importantly for existing depositors, withdrawal can be paused.
The implementation checks isWithdrawPaused() before processing a withdrawal request. If the withdrawal pause is active, the operation reverts.
This means the promise of an opportunity to exit must be understood in context.
A depositor may be able to withdraw during an ordinary governance timelock, provided withdrawals remain enabled and the position satisfies the market’s rules.
But a timelock does not override a separate emergency pause.
If the relevant guardian activates a withdrawal pause, a user cannot rely on the ordinary withdrawal function to escape that restriction.
This is not necessarily evidence of abusive control. An emergency pause may protect users when a vulnerability could otherwise let someone steal assets or spread accounting errors.
The same protection can temporarily prevent an innocent depositor from retrieving funds.
Those two consequences are not contradictory.
Security mechanisms sometimes preserve assets by restricting the operations that would normally make those assets accessible.
The extent of the restriction also depends on the precise protocol version and market configuration. Compound III’s withdrawal-pause authority should not be confused with the different emergency restrictions documented for the older Compound v2 architecture.
Nor does every unsuccessful withdrawal imply administrative intervention. Insufficient available liquidity, outstanding debt, collateralization requirements, or network conditions can independently prevent a user from completing an exit.
The key point is that a governance delay is not the same thing as an unconditional withdrawal guarantee.
What Depositors Should Actually Verify
A smart contract audit can establish useful facts about code quality. A governance forum can reveal what developers and token holders intend to change.
Neither source alone provides a complete picture of who can change the protocol after a deposit.
A more useful examination separates four questions.
First, what code is executing?
For an upgradeable market, the proxy address and its current implementation should be distinguished. A user needs to know whether the code they reviewed is actually the code the deployed proxy uses.
Second, who can replace it?
The relevant permissions may sit with a governance executor, timelock, multisignature wallet, administrator, or another contract that checks delegated authority.
An ownership address is a starting point, not necessarily the end of the investigation.
Third, how much notice is enforceable?
A voting period describes the time available for governance participation. A timelock describes the minimum waiting period before a queued action can execute.
The two should be measured separately. Users should also inspect whether any privileged role has a faster route to changing parameters or invoking emergency controls.
Fourth, is it possible to close the position?
A user may need to repay debt before withdrawing collateral. Available liquidity can affect withdrawals. An emergency pause may temporarily block them.
Even if an upgrade is visible several days in advance, the practical exit window depends on these other conditions.
For someone supplying an asset without borrowing against it, the relevant constraints may be relatively straightforward. For a leveraged position spread across multiple protocols, withdrawing collateral can require several transactions and sufficient external liquidity.
The complexity of the position determines how useful a governance warning really is.
A timelock offers information and time. It does not provide the liquidity, collateral, or operational permissions needed to complete every possible exit.
That difference deserves attention whenever a DeFi application advertises itself as non-custodial.
Non-custodial design can mean that no traditional intermediary holds the user’s assets in an account under its name. It does not automatically mean that no administrator can affect the conditions under which those assets are accessed.
Users can retain control of their wallet keys while remaining subject to rules maintained by upgradeable contracts.
These are different forms of control.
The Real Question Is Who Controls Tomorrow’s Code
Aave’s January 2026 upgrade problem and Compound III’s permission architecture illustrate two sides of the same issue.
Aave demonstrated that even an approved upgrade must satisfy the execution infrastructure’s restrictions before new rules can take effect.
Compound shows how an existing market can receive a new implementation through a proxy, while additional authorization layers and emergency controls determine who may perform certain actions.
Neither example proves that upgradeable DeFi is fundamentally unsafe.
Immutability without an upgrade path can create its own problems. A severe vulnerability in code that cannot be repaired may leave developers with fewer practical options than a protocol governed through carefully limited permissions.
But upgradeability introduces a security assumption that deserves to be examined explicitly.
Users are trusting more than the code currently handling their deposit. They are also relying on the mechanisms that decide what code may handle that deposit in the future.
Governance voting, timelocks, execution contracts, delegated administrators, and emergency guardians each contribute to that authority.
Their combined behavior matters more than any single declaration that a protocol is decentralized.
An investor looking at a DeFi lending market can verify the contract address, review its audits, and understand its collateral rules. Those checks establish something meaningful about the current system.
These checks do not answer whether the rules can change tomorrow.
To answer that, the investigation has to move beyond the deposit contract and follow the authority capable of replacing its logic.
The wallet may remain entirely under the user’s control.
The rules governing the money inside the protocol may not.
