Imagine: your stablecoin XUSD is trading at $1.05 on Uniswap, and the team can do nothing — market makers haven't arrived, liquidity is low. Depegging by 5% within an hour after launch. Without PSM (Peg Stability Module) this is inevitable. PSM is a smart contract that creates a built-in arbitrage mechanism, automatically maintaining the peg. We design and develop PSM tailored to your tokenomics, considering liquidity, and simulate behavior in stress scenarios.
The Math of Stabilization and Points of Failure
How the PSM Arbitrage Mechanism Works
Suppose your stablecoin XUSD trades at $1.02 on a DEX. PSM offers: bring $1 in USDC, get 1 XUSD (minus tin — fee on entry, e.g., 0.1%). An arbitrageur deposits 1000 USDC, receives 999 XUSD, sells them on Uniswap at $1.02, getting $1019.98. Profit $19.98 minus gas. After enough such trades, XUSD supply on the market increases, price drops to $1.00.
Reverse situation: XUSD = $0.98. PSM: bring 1 XUSD, get $1 USDC (minus tout — fee on exit). Arbitrageur buys 1000 XUSD for $980 on Uniswap, deposits into PSM, receives $999 USDC. Profit $19 minus gas. XUSD is bought off the market, price rises.
Key parameter — PSM debt ceiling. Without a ceiling, PSM can accumulate 100% reserves in one asset (e.g., USDC) — this concentrates regulator risk (Circle can freeze USDC). MakerDAO at its peak held over 50% of DAI reserves in USDC via PSM, leading to parameter revision after regulatory threats. Source: MakerDAO Governance
Attack Through Unbalanced PSM
If tin/tout is set too low (< 0.01%), PSM becomes a free arbitrage tool that drains reserves at any market shock. At XUSD = $0.995, arbitrage becomes profitable for volumes from $50K — MEV bots activate automatically.
Optimal tin/tout range for a new stablecoin at launch: 0.1–0.5%. As liquidity grows, reduce to 0.01–0.1%. These are configurable parameters that governance can change via timelock.
PSM Contract Architecture
Core Module Functions
// Entry: user deposits collateral, receives stablecoin function sellGem(address usr, uint256 gemAmt) external { uint256 gemAmt18 = gemAmt * (10 ** (18 - dec)); // normalize decimals uint256 daiAmt = gemAmt18; // 1:1 before fee uint256 fee = daiAmt * tin / WAD; // tin in WAD (1e18) require(dai.balanceOf(address(this)) >= daiAmt - fee, "PSM/insufficient-dai"); vow.bump(fee); // fee to treasury gem.transferFrom(msg.sender, address(this), gemAmt); dai.transfer(usr, daiAmt - fee); emit SellGem(usr, gemAmt, fee); } // Exit: user deposits stablecoin, receives collateral function buyGem(address usr, uint256 gemAmt) external { uint256 gemAmt18 = gemAmt * (10 ** (18 - dec)); uint256 daiAmt = gemAmt18; uint256 fee = daiAmt * tout / WAD; require(gem.balanceOf(address(this)) >= gemAmt, "PSM/insufficient-gem"); dai.transferFrom(msg.sender, address(this), daiAmt + fee); vow.bump(fee); gem.transfer(usr, gemAmt); emit BuyGem(usr, gemAmt, fee); } Critical point — decimals normalization. USDC has 6 decimals, most stablecoins have 18. Without gemAmt * (10 ** (18 - dec)), PSM arithmetic breaks — user gets 10^12 times fewer tokens. Even experienced developers make decimals errors when dealing with non-standard ERC-20.
Collateral Whitelist and Multi-Asset PSM
Basic PSM works with one collateral. An extended version supports multiple: USDC, USDT, DAI — each with its own tin/tout and debt ceiling parameters.
Adding new collateral via governance: addGem(address gemAddress, uint256 ceiling) with a minimum 48-hour timelock. This prevents adding a malicious ERC-20 with custom transferFrom that drains PSM through reentrancy.
How RateLimiter Protects PSM from Flash Loan Attacks
Flash loan attack on PSM: borrow USDC, dump into PSM via sellGem, get XUSD, sell on market, create artificial price pressure, buy XUSD back cheaper, return to PSM, repay flash loan with profit. To neutralize — RateLimiter: maximum operation volume in PSM over N blocks.
mapping(uint256 => uint256) public volumePerBlock; uint256 public constant MAX_VOLUME_PER_WINDOW = 1_000_000e18; // 1M stablecoins uint256 public constant WINDOW_BLOCKS = 50; // ~10 minutes function _checkRateLimit(uint256 amount) internal { uint256 windowStart = block.number - (block.number % WINDOW_BLOCKS); volumePerBlock[windowStart] += amount; require(volumePerBlock[windowStart] <= MAX_VOLUME_PER_WINDOW, "PSM/rate-limit"); } Governance and Parameter Management
Which PSM Parameters Are Critical for Security?
PSM without governance is a static tool. PSM with governance is a living market mechanism. Parameters that must be in governance:
| Parameter | Description | Recommended Timelock |
|---|---|---|
tin |
Fee on entry | 24 hours |
tout |
Fee on exit | 24 hours |
line (debt ceiling) |
Max volume | 48 hours |
addGem |
New collateral | 72 hours |
pause |
Halt PSM | 0 (emergency) |
For new protocols, we recommend Gnosis Safe + OpenZeppelin TimelockController. Pause is the only operation without timelock but requires a multisig (minimum 3/5).
Process of Work
Analysis and simulation (2–3 days). Python script simulates PSM behavior under different volatility scenarios: peg deviation 1%, 3%, 5%, flash crash. We select optimal tin/tout and debt ceiling. Analyze target stablecoin liquidity on DEX — this determines minimum PSM size.
Development (4–6 days). Core PSM contract, RateLimiter, multi-asset support if needed, governance integration. Foundry tests: unit tests for all functions, fuzz tests for edge-case decimals and amounts, fork tests with real USDC/USDT.
Audit (2–3 days). Slither, manual review of decimals handling and overflow/underflow (critical for Solidity < 0.8.0; in 0.8+ SafeMath is built-in, but custom unchecked blocks require attention).
Deployment (1–2 days). Testnet first, mainnet via multisig with verification.
Basic PSM with one collateral — 1–1.5 weeks. With multi-asset support, governance, and dashboard — 2–3 weeks. Cost is calculated individually after tokenomics analysis.
Typical PSM Development Mistakes
- Incorrect decimals normalization — one of the most common and dangerous.
- Missing rate limiter — PSM becomes vulnerable to flash loan attacks.
- Too low tin/tout — arbitrage becomes ineffective, PSM can be drained.
- Too high debt ceiling — concentrates centralization risk of reserves.
What You Get
Upon completion, you receive:
- PSM contract source code with comments
- Audit report (Slither + manual code review)
- Technical documentation for deployment and management
- Multisig contracts (Gnosis Safe + TimelockController)
- Operations manual for your team
- Technical support for 14 days after deployment
Our experience: over 10 years in DeFi, 15+ launched stablecoins, 5 years in blockchain development. We guarantee stable PSM operation and adherence to best security practices.
Order PSM development — contact us for a consultation and project evaluation. Get a free engineer consultation.