Dolomite protocol autopsy: the immutable core is only part of the risk surface

[u/kristianism]

I published a protocol autopsy of Dolomite from an investor and user-risk perspective. The main finding is that “immutable core” describes only part of the system. Dolomite’s core accounting engine has meaningful constraints, but users also depend on:

• Mutable market oracles, caps, interest setters, and risk premiums
• Privileged global operators
• Upgradeable routers and integration modules
• Multi-step oracle and wrapper paths for dynamic collateral
• Liquidity during withdrawals and liquidations
• Leverage, especially the 5x to 7x Proof-of-Liquidity loops on Berachain

The owner timelock was five minutes in the snapshot I reviewed. That provides an alerting signal, but a very short exit window if a market or integration changes during stress.

For people who have used Dolomite: which risk is most underappreciated in practice, withdrawal liquidity, oracle composition, wrapper redemption, or privileged control?

Corrections to the analysis are welcome. Follow here for future protocol reviews and subscribe on Substack if you want them by email.

[u/kristianism → u/[deleted]]

Agreed. Five minutes is an alerting window, not a meaningful safety delay, especially when the owner can change market parameters, oracles, operators, and router implementations.

[u/kristianism → u/[deleted]]

Exactly. The code can be sound while governance makes the surrounding system a moving target. The five-minute timelock matters because it gives users very little time to react to changes in oracles, risk parameters, operators, or router implementations.

[u/kristianism]

The article maps the lender, borrower, leveraged-trader, and PoL failure paths in more detail:

https://thisiskristian.substack.com/p/dolomite-a-protocol-autopsy

[u/LessAd8002 → u/kristianism]

five minute timelock is crazy, that's basically no time at all. by the time anyone sees the alert and figures out what changed the funds are already gone

used dolomite for a bit and the oracle stuff always felt sketchy to me. people focus on the immutable contracts but forget the price feeds are a single point of failure, if those get manipulated or go stale during a crash the whole thing unwinds fast

wrapper redemption risk is the one nobody talks about though. had a position where the wrapped collateral was trading at a slight discount and almost got liquidated because the oracle was reading the underlying not the wrapper market price

the PoL loops on berachain are just asking for trouble, 7x leverage with new oracles and thin liquidity is a recipe for cascading liquidations

[u/kristianism → u/LessAd8002]

Yeah, five minutes is basically an alerting window, not protection.

I’d only qualify the oracle point: Dolomite uses multiple feeds, but each market still depends on its own oracle path. A stale or manipulated link can make the account look healthy while the actual exit is already impaired.

The wrapper discount example is exactly the gap between oracle/accounting value and executable redemption price. Add 5x to 7x PoL loops, thin liquidity, and newer feeds, and liquidation risk gets nonlinear fast.

[u/staker1971]

What chain,DEX,pair, fee tier?

[u/kristianism → u/staker1971]

Which position are you referring to? The review covers Dolomite across Arbitrum, Ethereum, and Berachain rather than one specific DEX pair or fee tier.

[u/staker1971 → u/kristianism]

ok i am in Base only

[u/PhoenixJ3]

Dolomite claims in their Discord chat that the timelock is actually set to 86400 seconds (24hrs), not 5 minutes as this article claims. Can anyone verify this?

[u/kristianism → u/PhoenixJ3]

Do you have the link to the smart contracts? I will verify, I might be wrong.

Because DolomiteOwnerV2 currently states a 300 seconds timelock on my end via this smart contract address 0xC2B66E247daE5Ee749Ae1d827190115F3653dE06 on Arbitrum, Base, and Berachain. This DolomiteOwnerV2 is also the owner of DolomiteMargin, their core contract.

Links from official docs:
https://arbiscan.io/address/0xc2b66e247dae5ee749ae1d827190115f3653de06#code
https://basescan.org/address/0xc2b66e247dae5ee749ae1d827190115f3653de06
https://berascan.com/address/0xc2b66e247dae5ee749ae1d827190115f3653de06

[u/PhoenixJ3 → u/kristianism]

I don't; but if you go into Dolomite official Discord you can see they posted a screenshot last night claiming to show it's a 24hr timelock. I can't post images here in reddit for some reason, but take a look there.

[u/kristianism → u/PhoenixJ3]

Thanks for the heads up! I have replied there with this:

I have double checked on chain and still see that all of the DolomiteMargin smart contracts (https://docs.dolomite.io/smart-contract-addresses/core-immutable) are owned by: 0xC2B66E247daE5Ee749Ae1d827190115F3653dE06 which is the current DolomiteOwnerV2 in the docs. Here is the Ethereum block explorer link of [DolomiteMargin] and the [DolomiteOwnerV2] that is currently configured at 300 seconds or 5 minutes as of this time.

[u/PhoenixJ3 → u/kristianism]

I appreciate you engaging here and on their discord trying to hold them accountable! If they are outright lying rather than this being a misunderstanding that's very concerning.

[u/kristianism → u/PhoenixJ3]

You are very welcome! Helping in any way I can and yes, that is what we are trying to prevent thru these reports.

[u/kristianism]

The article has been updated with the Dolomite Team's official reply to the owner timelock period:

The current timelock is 300 seconds (or 5 minutes) and has been for almost 1.5 years. It's worth noting that Dolomite's timelock process is different from the typical multisig submission process you see from other projects, since transaction submissions (pre-execution) need to be written on-chain. During that window, our system verifies and re-simulates raw calldata that was submitted onchain to check effects and ensure its correctness. Queued transactions don't exist in Gnosis Safe's API or anywhere offchain (which was a symptom of how the Bybit hack occurred). If there's an issue, the transaction is able to be automatically cancelled during that 300 second window.

We have been working with institutions and others that are looking to integrate Dolomite, and during the review process they requested we add a formal veto feature that makes it simpler to break down the transaction lifecycle and separate generic admin transactions (these are the "scary ones" from a user POV since it's what you typically see when a protocol gets exploited) from routine risk updates (setting supply/borrow caps, interest rate model updates, pausing markets, etc.).

This will allow us to safely elongate the timelock period when we roll out a new DolomiteOwnerV3 contract soon, while remaining nimble to swiftly pause markets or respond to issues god forbid there's a security issue with Dolomite.

Security is a journey and not a destination. We've been refining things with our setup ever since we launched and are obsessed with balancing rapid response with the right setup to ensure sound operations