Contracts and immutability
Code that has never been audited, has no upgrade path, and cannot be corrected. What immutability buys, what it costs, and what a second version would mean for someone already in the first.
Spec v0.9.1, reviewed 2026-09-08
Every protection on the other risk pages rests on the contracts behaving as described. Nothing has been audited, nothing has been deployed, and once it is, no line of it can be changed. This page is about that.
No audit has been completed
No audit, no contest, no formal review, no production history. The sequence that has to finish before any deployment is on Security contact; at the time of writing none of it has started, because the specification is still being red-teamed.
Until that sequence has finished, the correct assumption about this code is that it contains defects nobody has found.
Risk
The launch plan itself is a risk statement: four branches at one hundred thousand dollars of debt each for fourteen days. The reason for that number is that it is what the design is willing to lose to a defect nobody caught.
A new codebase, written from scratch
No line is copied from an existing protocol. Where a mechanism resembles one that exists — the product-sum pool accounting, the rate-ordered list, the borrower-set rate, the permissionless shutdown — it is reimplemented from the specification rather than transcribed.
What that buys. No inherited licence problem, and no inherited defect from a codebase whose assumptions do not hold here.
What it costs. No inherited scrutiny either. A mechanism that has run for four years on another protocol has been attacked for four years. The same mechanism rewritten has been attacked for none.
There is no upgrade path
Across the core modules and the token and vault modules there is no proxy, no setter, no timelock, no administrative role, no migration function and no selfdestruct. Every parameter is fixed by the constructor, computed on-chain from a formula, or opened by a step whose date was written before deployment. A deployment test asserts that no contract has a non-zero owner and that every cross-address matches.
Guarantee
Nobody can change a parameter, replace an oracle, add a collateral branch, blocklist an address, pause a repayment or mint against a position. Not the development team, not a vote, not a key. The functions are absent from the bytecode, which anyone can verify.
Rules P7, R-12.2.1, R-12.2.2
A wrong constant stays wrong
The specification freezes roughly two hundred numbers. Some are measured, some are estimated and marked as such, and every one of them is final at the moment the deployment transaction lands.
| If this turns out wrong | The consequence, for the life of the deployment |
|---|---|
| A liquidation threshold too low for its tier | The pool takes a loss on every fast fall, and the branch accumulates bad debt |
| A depth reference too high | Sources are disqualified that should have counted, and branches sit degraded |
| A liquidity vault range too narrow | The position leaves its range and the pool stops quoting |
| The volatility constant too permissive | Positions are opened closer to the threshold than the design intended |
| A rate floor too high | Nobody borrows, and there is no yield for anyone |
None of these is repaired. Each is either absorbed, or it closes its branch, or it is fixed in a different deployment that nobody is obliged to move to.
The constants marked as estimates rather than measurements are listed on What is measured before launch, and the whole table with its provenance is on Parameters.
A failing component closes its branch
There is no repair path, so the design substitutes an orderly closure. Each of these is permissionless: anyone can call it, and nobody can stop it.
| Condition | What happens |
|---|---|
| No valid exchange price for 7 days | The branch shuts down. Urgent redemptions open the same day, borrowers repay and close, and what is left settles 30 days later |
| The branch ratio under 110% for an hour, in a regime where the pool could act | The same |
| The collateral token upgraded and the automatic transferability test never passing | The freeze extends in weekly steps to four weeks, then the branch shuts down |
| 3 branches shut down, or the aggregate ratio under 110% | The whole protocol enters its terminal mode |
One clock governs all of it. Urgent redemptions open 0 days after a closure triggered by any automatic cause, and 7 days after one ordered by the Closer key, which is the delay that lets borrowers act before holders do. Settlement follows 30 days after redemptions open, whichever cause it was.
A closed branch is not a loss by itself: borrowers repay and take their collateral, holders redeem at the last accepted price. What it costs is the position you wanted to keep, closed at a moment you did not choose. The mechanism is on Sunset.
The one human power, and its expiry
A 2-of-3 Safe can freeze and can close. It cannot mint, cannot modify anything, cannot touch a repayment or a withdrawal, cannot activate a branch, cannot reopen what it closed, and cannot extend its own life. It does not know the oracle contracts, the volatility oracle, or any FBR or vault contract. It expires 365 days after deployment, and every function reverts thereafter.
Risk
A key that can close is a key that can close wrongly. A shutdown on a false positive kills a branch that was healthy, and there is no reopening. The published doctrine is to freeze first, for at most 72 hours, and to close only on confirmation. That is a commitment about behaviour, not a property of the code.
Rule R-12.1.2
The opposite risk is worth stating with the same weight. With no key at all, a defect found by a researcher before it is exploited has no response but a public warning, which is also a public invitation. An immutable protocol on another chain lost roughly three quarters of a million dollars in August 2026 with no button to press. The key exists for eleven months of first-time-in-production code, and then it does not.
Its whole value depends on somebody watching. That is a commitment the development addresses make off-chain, and it is worth exactly what such a commitment is worth.
What a second version means if you are in the first
A version 2 is a separate deployment: new contracts, a new stablecoin, new branches, no state migration and no automatic move.
Version 1 does not die. It keeps working, keeps accruing, keeps liquidating and keeps redeeming, and its ladders stop climbing beyond the step they reached. Nobody can shut it down to force a migration once the key has expired.
Nothing moves you. No function migrates a position. You repay in version 1 and open in version 2 if you choose to, and if you choose not to, nothing changes for you.
The only bridge is economic. A version 2 peg module may accept version 1 fyUSD at par, up to its own cap, which puts a floor under the old stablecoin without obliging anybody.
Risk
In practice a second deployment splits liquidity, splits the Stability Pools and splits the depositor base. The version that keeps the depth keeps the safety, and there is no mechanism that decides which one that is.
Rule R-12.4
What is genuinely verifiable, today
The claims on this page are checkable rather than trusted, and that is the only compensation immutability offers.
- The absence of a setter, a proxy or an owner: readable in the bytecode.
- The parameter values: readable in the constructor arguments.
- The key's expiry: an immutable timestamp, one call to read.
- The minter set of the stablecoin: fixed at construction, one call to read.
- The source registry of each branch: fixed at construction, published, one call per source.
The properties that must hold across every call sequence are on Invariants.
Liquidation and bad debt
How far a price may fall before a liquidation stops covering the debt, what an earnings minute does to a tier 2 branch, and the three layers that absorb the shortfall.
Issuer and freeze
The collateral is a certificate, not a share. What happens if the entity behind it fails, freezes a balance, upgrades its contract, or runs a corporate action nobody anticipated.