Skip to main content
This page states plainly what is immutable, what the protocol admin can change, what it can never do, and which third parties Denar necessarily trusts.

What is immutable

The lending core has no upgrade mechanism, no pause button, no backdoor. Each market’s defining parameters — collateral asset, oracle, interest model, LLTV — are fixed forever at creation. Nobody, including the Denar team, can change the rules of a market you have already entered. Changing oracle behavior requires deploying a new market and letting users migrate by choice.

What the admin can do — and the hard limits

The timelock: depositors’ early warning

Every action that increases lender risk — raising a cap, adding a market to the vault — sits in a public pending state for 1 day before it can take effect. Anyone watching the chain sees it coming and can exit first. Actions that decrease risk (cutting a cap, down to zero) execute instantly. The timelock itself cannot be set below 1 day or above 2 weeks.

Trust assumptions

Current administration, honestly

Admin roles are currently held by the deploying address — a single key, publicly identifiable on the Contracts page. This is a deliberate bootstrap choice for the seed phase, made viable by how little the admin can actually do (see the table above) and by the tiny caps. The hardening path, in order: a dedicated operational key for the liquidation bot, then a multisig for the owner and curator roles, then a separate guardian with veto-only power over pending risk increases — each step planned before caps rise meaningfully.
The strongest guarantee is structural, not procedural: the vault is ERC-4626 non-custodial and the core is immutable. “The admin curates risk but never custodies funds” is a property of the code, not a promise.

Responsible disclosure

Found a vulnerability? Reach the team through denar.markets. Good-faith reports are welcome and acted on quickly; a formal bug-bounty program is planned alongside the external audit.