Представьте: ваш стейблкоин XUSD торгуется по $1.05 на Uniswap, а команда ничего не может сделать — маркет-мейкеры не пришли, ликвидность низкая. Depegging на 5% уже через час после запуска. Без PSM (Peg Stability Module) это неизбежно. PSM — это смарт-контракт, который создаёт встроенный арбитражный механизм, автоматически удерживающий привязку. Мы проектируем и разрабатываем PSM под вашу токеномику, с учётом ликвидности и моделируем поведение в стресс-сценариях.
Математика стабилизации и точки отказа
Как работает арбитражный механизм PSM
Допустим, ваш стейблкоин XUSD торгуется по $1.02 на DEX. PSM предлагает: принеси $1 в USDC, получи 1 XUSD (минус tin — fee on entry, например 0.1%). Арбитражник вносит 1000 USDC, получает 999 XUSD, продаёт их на Uniswap по $1.02, получает $1019.98. Профит $19.98 минус газ. После достаточного количества таких сделок supply XUSD на рынке вырастет, цена снизится к $1.00.
Обратная ситуация: XUSD = $0.98. PSM: принеси 1 XUSD, получи $1 USDC (минус tout — fee on exit). Арбитражник покупает 1000 XUSD за $980 на Uniswap, вносит в PSM, получает $999 USDC. Профит $19 минус газ. XUSD выкупается с рынка, цена поднимается.
Ключевой параметр — debt ceiling PSM. Без потолка PSM может накопить 100% резервов в одном активе (например, USDC) — это концентрирует риск регулятора (Circle может заморозить USDC). MakerDAO на пике держал более 50% резервов DAI в USDC через PSM, что привело к пересмотру параметров после угроз регуляторов. Источник: MakerDAO Governance
Атака через несбалансированный PSM
Если tin/tout установлен слишком низко (< 0.01%), PSM превращается в бесплатный арбитражный инструмент, который высасывает резервы при любом рыночном шоке. При XUSD = $0.995 арбитраж становится выгодным при объёме от $50K — MEV-боты включаются автоматически.
Оптимальный диапазон tin/tout для нового стейблкоина на старте: 0.1-0.5%. По мере роста ликвидности — снижение до 0.01-0.1%. Это конфигурируемые параметры, которые governance может изменять через timelock.
Архитектура PSM контракта
Корневые функции модуля
// Вход: пользователь вносит collateral, получает стейблкоин
function sellGem(address usr, uint256 gemAmt) external {
uint256 gemAmt18 = gemAmt * (10 ** (18 - dec)); // нормализация decimals
uint256 daiAmt = gemAmt18; // 1:1 до комиссии
uint256 fee = daiAmt * tin / WAD; // tin в WAD (1e18)
require(dai.balanceOf(address(this)) >= daiAmt - fee, "PSM/insufficient-dai");
vow.bump(fee); // комиссия в казну
gem.transferFrom(msg.sender, address(this), gemAmt);
dai.transfer(usr, daiAmt - fee);
emit SellGem(usr, gemAmt, fee);
}
// Выход: пользователь вносит стейблкоин, получает 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);
}
Критичный момент — нормализация decimals. USDC имеет 6 decimals, большинство стейблкоинов — 18. Без gemAmt * (10 ** (18 - dec)) арифметика PSM сломается — пользователь получит в 10^12 раз меньше токенов. Ошибку decimals делают даже опытные разработчики при работе с нестандартными ERC-20.
Whitelist коллатералей и мультиактивный PSM
Базовый PSM работает с одним collateral. Расширенная версия поддерживает несколько: USDC, USDT, DAI — каждый с собственными параметрами tin/tout и debt ceiling.
Добавление нового collateral через governance: addGem(address gemAddress, uint256 ceiling) с timelock минимум 48 часов. Это предотвращает добавление вредоносного ERC-20 с кастомным transferFrom, который дренирует PSM через reentrancy.
Как RateLimiter защищает PSM от flash loan атак
Flash loan атака на PSM: занять 10M USDC, вломиться в PSM через sellGem, получить 10M XUSD, продать на рынке, создать искусственное давление на цену, купить XUSD обратно дешевле, вернуть в PSM, вернуть flash loan с прибылью. Для нейтрализации — RateLimiter: максимальный объём операций в PSM за N блоков.
mapping(uint256 => uint256) public volumePerBlock;
uint256 public constant MAX_VOLUME_PER_WINDOW = 1_000_000e18; // 1M стейблкоинов
uint256 public constant WINDOW_BLOCKS = 50; // ~10 минут
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 и управление параметрами
Какие параметры PSM критичны для безопасности?
PSM без governance — статический инструмент. PSM с governance — живой рыночный механизм. Параметры, которые должны быть в governance:
| Параметр | Описание | Рекомендуемый timelock |
|---|---|---|
tin |
Fee on entry | 24 часа |
tout |
Fee on exit | 24 часа |
line (debt ceiling) |
Макс. объём | 48 часов |
addGem |
Новый коллатераль | 72 часа |
pause |
Остановка PSM | 0 (экстренная) |
Для новых протоколов рекомендуем Gnosis Safe + TimelockController OpenZeppelin. Pause — единственная операция без timelock, но требует мультисиг (минимум 3/5).
Процесс работы
Аналитика и моделирование (2-3 дня). Python-скрипт моделирует поведение PSM при разных сценариях волатильности: peg deviation 1%, 3%, 5%, flash crash. Подбираем оптимальные tin/tout и debt ceiling. Анализируем ликвидность целевого стейблкоина на DEX — от этого зависит минимальный размер PSM.
Разработка (4-6 дней). Core PSM контракт, RateLimiter, мультиактивная поддержка если нужна, governance интеграция. Foundry тесты: unit тесты для всех функций, fuzz-тесты на граничные значения decimals и amount, fork-тесты с реальными USDC/USDT.
Аудит (2-3 дня). Slither, ручной review decimals handling и overflow/underflow (critical для Solidity < 0.8.0; в 0.8+ SafeMath built-in, но кастомные unchecked блоки требуют внимания).
Деплой (1-2 дня). Testnet сначала, mainnet через multisig с верификацией.
Базовый PSM с одним collateral — 1-1.5 недели. С мультиактивной поддержкой, governance и дашбордом — 2-3 недели. Стоимость рассчитывается индивидуально после анализа токеномики.
Типичные ошибки при разработке PSM
- Неверная нормализация decimals — одна из самых частых и опасных.
- Отсутствие rate limiter — PSM становится уязвим для flash loan атак.
- Слишком низкие tin/tout — арбитраж перестаёт быть эффективным, PSM может быть drained.
- Слишком высокий debt ceiling — концентрирует риск централизации резервов.
Что вы получите
По итогам разработки вы получаете:
- Исходный код PSM-контракта с комментариями
- Аудиторский отчёт (Slither + ручной code review)
- Техническую документацию по развёртыванию и управлению
- Мультисиг-контракты (Gnosis Safe + TimelockController)
- Инструкцию по эксплуатации для команды
- Техническую поддержку в течение 14 дней после деплоя
Наш опыт: более 10 лет в DeFi, 15+ запущенных стейблкоинов, 5 лет на рынке блокчейн-разработки. Мы гарантируем стабильную работу PSM и его соответствие лучшим практикам безопасности.
Закажите разработку PSM — свяжитесь с нами для консультации и оценки вашего проекта. Получите консультацию инженера бесплатно.