Monolith Stablecoin Factory
Monolith is a stablecoin-as-a-service platform being launched by Inverse Finance, enabling permissionless creation of immutable, over-collateralized stablecoins using any collateral with an on-chain price feed. Monolith's design features interest-bearing vaults for stablecoin holders, autonomous interest rate controllers, and deployer fee access, all optimized for security, scalability, and cross-chain expansion.
Details
Scope
On what chains are the smart contracts going to be deployed?
Ethereum Mainnet
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
Monolith allows permissionless deployment with any ERC20 token that has a valid Chainlink price feed. The PSM feature supports both standard ERC20 tokens and ERC4626 vault tokens.
For collateral tokens:
Must have a reliable Chainlink oracle (the denominator is expected to be a fiat currency whose price is a few orders of magnitude of the USD price (e.g. Euro, Turkish Lira, Russian Ruble), and the oracle has to exist on the Ethereum mainnet).
Can be any ERC20-compliant token (6-18 decimals)
ERC4626 tokens are supported for PSM yield generation
Known restrictions:
Fee-on-transfer tokens are not supported
Rebasing tokens are not supported in the current version
ERC777 tokens may present reentrancy risks (addressed via checks-effects-interactions pattern)
Collateral tokens with very large amount of decimals or very small amount of decimals may cause exacerbated rounding errors
Synthetic asset oracles with a very large price per token may cause exacerbated rounding errors or not work well with the global minimum debt floor
Only standard ERC20 tokens (with 6-18 decimals) are expected to be in scope.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
Operator role (set at deployment, mutable before immutability deadline):
Trusted to set reasonable parameters before the immutability deadline
Trusted to deploy Monolith coin with a safe oracle and collateral
Trusted to deploy Monolith coin with safe parameters
Can adjust: collateral factor, liquidation parameters, redemption fees, PSM fees, interest rate model parameters
Cannot change core protocol logic after immutability deadline
Factory owner:
Trusted role
Sets global parameters like minimum debt floor
Post-immutability deadline:
No admin can modify protocol parameters
Protocol becomes fully immutable except for fees
Key constraints:
Collateral Factor: Must be ≤ 85% (current factory setting)
Minimum debt floor: Set at factory level
PSM buy fee: Grows linearly from 0% to 1% over the second half of the immutability deadline
Operators creating new Monolith Coins (deployers of Monolith coins) should be trusted to have set up a safe coin. That means if the operator/deployer creates a Monolith coin with malicious/faulty collateral, the oracle of the PSM vault and depositors lose funds after interacting with it -> this is not considered a valid issue. The same applies to unsafe risk parameters (e.g. using too high collateral factor for an extremely volatile coin).
However, the operator/deployer of the Monolith coin shouldn't be able to steal funds, yield or mint tokens outside of borrowing with safe/trusted collateral, oracle and PSM vaults. If changing parameters of the monolith coin allows them to steal user funds or nuke the price of the monolith coin, that can be viewed as a valid finding.
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
We integrate primarily with Chainlink oracles and assume that Chainlink governance will operate correctly. However, we implement staleness checks as a safety mechanism set on deployment.
For PSM integrations with other stablecoins or ERC4626 vaults, we trust the underlying protocol's governance but isolate risk to PSM deposits only.
Is the codebase expected to comply with any specific EIPs?
ERC20: Full compliance for the Coin contract
ERC4626: Full compliance for the Vault contract
Chainlink Oracle Interface: Standard latestRoundData() interface compliance
Issues that break the EIP's MUST statements may be deemed valid Medium severity (even if the violation is in view functions and doesn't impact state functions) even if the impact is low/info, unless they conflict with common sense.
Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
Liquidation bots: External actors are expected to monitor positions and trigger liquidations when positions become undercollateralized. The protocol provides economic incentives (liquidation fees) for this. Assume they only liquidate if the liquidation incentive covers the fee. Assume that Monolith Coin holders have an incentive to call the writeOff function if a position goes into bad debt.
Redemption actors: Free debt borrowers can be redeemed against when the stablecoin trades below peg. Market participants are expected to perform these redemptions for profit.
Oracle updates: Chainlink oracles update prices off-chain based on their decentralized network.
All off-chain mechanisms are incentivized and permissionless - no trusted keepers are required.
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?
Critical invariants:
Collateral accounting: Total collateral in the protocol must always be ≥ sum of all individual user collateral balances
Debt accounting: Total debt must always be equal to or greater than the circulating supply of stablecoins (excluding PSM-backed supply)
Share price monotonicity: Debt share prices should never decrease (except during write-offs for bad debt socialization)
PSM reserves: PSM reserves must always be sufficient to redeem all PSM-backed stablecoin supply
Liquidation safety: Positions below the collateral factor threshold must always be liquidatable
Interest accrual: Interest must always accrue correctly based on time elapsed and current rate
Redemption fairness: Redemptions should proportionally reduce collateral from free debt borrowers
nonRedeemableCollateral must be at least equal to the sum of all Non redeemable users' balances
Due to rounding errors, it's expected that total supply and total debt don't align perfectly, but in those cases, the debt should be rounded up in favour of the protocol.
Please discuss any design choices you made.
Dual Debt System: We implemented both paid (variable rate) and free (0% but redeemable) debt to allow borrowers to choose their risk profile. This creates a natural market mechanism for interest rate discovery.
Bad Debt Socialization: The writeOff function socializes bad debt across all borrowers proportionally. This was chosen over alternative liquidation mechanisms to ensure protocol solvency. In extreme scenarios with very high share deflation (>1M shares per 1 unit of underlying), this is considered an acceptable risk given it would require catastrophic failure of risk management.
PSM Yield Capture: Yield from ERC4626 PSM vaults goes to the operator to incentivize protocol deployments and provide sustainable revenue.
Interest Rate Controller: The autonomous interest rate controller adjusts rates based on the free debt ratio to maintain system equilibrium. We chose aggressive halving/doubling periods (configurable by operator) to encourage rapid market response.
Immutability Deadline: We chose a fixed immutability deadline approach rather than upgradeable contracts to provide certainty to users, even at the cost of flexibility.
Please provide links to previous audits (if any) and all the known issues or acceptable risks.
Please list any relevant protocol resources.
Additional audit information.
Security researchers should not assume there will be any immediate deposits (deposits on deployment) to yield vaults (Vault.sol contract) for monolith coins.
Total Rewards
Contest Pool
Lead Senior Watson
Lead Judge
25,500 USDC
6,500 USDC
2,500 USDC
Status
Scope
Start Time
End Time
Judging Rules
