Institutional-Grade Security. Chapter 1: Guardrails and Role Separation

For years, crypto operated under the mentality of “only invest what you’re ready to lose.” With institutional adoption on the horizon, this mindset is no longer sufficient. The challenge now is delivering proper institutional-grade security without sacrificing decentralization. This is the first article of a series that will walk through how we approached that problem at @GearboxProtocol

Our starting point was the motivation: in 2024, the protocol had multiple pools, diverse collateral types, and a wide range of assets — all of which made DAO-level risk management increasingly difficult and ultimately limited scalability.

Echoing Vitalik’s perspective, meaningful ecosystem growth comes from systems that reduce backdoors, increase decentralization, strengthen privacy, and adopt open-source practices — all while enhancing, not compromising, security:

Institutional players won’t trust a pool governed solely by a DAO; they want to manage markets themselves. That realization became a key driver behind redesigning our system.

Challenge

Our core question was simple: How do we migrate from a system with ~$400M TVL to a permissionless model without forcing users to move their liquidity?

That question splits into two parts:

Part A. Protecting users from malicious curators
Allowing individuals to manage markets permissionlessly introduces risk. Curators need the flexibility to respond to emergencies — but not enough authority to abuse the system or put users at risk. Traditional timelocks alone cannot solve this.

Part B. Protecting the protocol from potential misconfiguration
Even well-intentioned curators can make catastrophic mistakes. History shows this clearly:

The Morpho PAXG/USDC market (tokenized gold via @Paxos) was exploited, leading to a $230K loss.

The root cause? A misconfigured oracle pricing gold at $2.6 trillion USD.In the @Morpho PAXG/USDC market, a misconfigured oracle valued tokenized gold at $2.6 trillion per ounce. Attackers quickly exploited the overpriced collateral and exited with ~$230K.Cases like this highlight a simple truth: protocols must minimize the impact of human error.

Designing guardrails

To achieve institutional-grade security in a permissionless environment, we began by listing every possible edge case we could imagine. For months, we analyzed how a malicious curator might create honeypots for LPs or borrowers and extract funds.

Example: LTV (Loan-to-Value) configuration
On one hand, this parameter is part of the curator’s responsibility, so they should be able to adjust it at any time. On the other hand, if a curator suddenly sets LTV too low, it could trigger a wave of liquidations, drain AMM pools, and—once the price impact propagates back through the price oracle—create a death spiral that ends in bad debt.

After a series of discussions, we arrived at a single safe mechanism for changing LTV: ramping. There is no function to change the value immediately (even after the timelock). Instead, curators can only define a linear adjustment over time, with a minimum duration of 24 hours. This ensures that any downgrade happens gradually, preventing sudden liquidation cascades and avoiding excessive market pressure.

Provide a caption (optional)The 24-hour minimum is hardcoded and cannot be modified by curators, but the system still provides them with enough flexibility to manage risk safely.

Emergency toolset

We also developed a comprehensive emergency action toolset designed for cases where immediate intervention is required. These tools proved invaluable during the XUSD collapse, where Gearbox avoided $30M in potential bad debt, as described by the Invariant team: https://x.com/0xmikko_eth/status/1985667219599106107

In Gearbox, curators can forbid specific tokens, adjust interest rate curves, or increase liquidation thresholds to mitigate risks associated with toxic assets.

Example: Safely switching price oracles
Gearbox is fully agnostic to oracle issues. If an oracle stops updating or returns incorrect data, curators can immediately switch to another oracle from the on-chain catalog (a mapping that stores multiple approved price feeds per asset, I’ll cover this in more detail in Chapter 5).

Why is the ability to change oracles so important?
Because keeping oracles immutable, as some protocols do, creates a dangerous failure mode: if the oracle breaks or becomes inaccessible, user funds can become effectively locked forever. Allowing oracle rotation eliminates this systemic risk.

But this introduces a new risk: Instance owners — who manage the catalog — can add new oracles without a timelock. In theory, a malicious curator + malicious instance owner could add a malicious oracle and then immediately switch to it, harming users.To eliminate this attack vector, we introduced a simple and effective safeguard:

Even in emergency mode, a newly added oracle must exist in the catalog for at least 2 days before it can be used.

This keeps the timelock guarantee intact while still allowing curators to respond quickly to genuine emergencies.

Role separation

The next major step was introducing a clear separation of responsibilities.

Today, the DAO operates with intentionally limited influence. Even if governance were compromised, it cannot directly change user positions or interfere with curated markets. This is by design.

Gearbox uses several independent layers:

The DAO (token holders)
Responsible only for high-level, global parameters with strict contract-level limits, managing whitelisted auditors and new protocol version.

Instance Owners (Instance Managers)
Maintain chain-specific parameters such as price-feed allowlists and ensure that configurations remain accurate across networks.

Market Curators
Responsible for creating, managing, and closing markets. Any action affecting borrow limits, collateral parameters, or user positions must pass through a timelock.

This separation ensures that no single role — not even the DAO — can compromise protocol integrity.

More details on how this multi-layer structure works across networks, why it doesn’t rely on bridges, and how governance batches are chained together will be covered in the next chapter.

Stay tuned!

Github: https://github.com/Gearbox-protocol/permissionless
Docs: https://docs.gearbox.fi/gearbox-permissionless-doc
Permissionless interface: https://permissionless.gearbox.foundation/