DeFi

Suilend – обзор lending, SpringSui, STEAMM, SEND и рисков

Подробный обзор Suilend: main и isolated markets в Sui, ставки, ликвидации, SpringSui и sSUI, STEAMM, SEND, mdrop, управление и риски.

Suilend – обзор lending, SpringSui, STEAMM, SEND и рисков

Suilend – DeFi-система в сети Sui, которая выросла из lending protocol в набор продуктов для кредитования, liquid staking и торговли. Основной рынок объединяет крупные активы в общий collateral system, isolated markets отделяют более рискованные токены, SpringSui выпускает liquid staking assets, а STEAMM соединяет AMM liquidity с денежным рынком.

Токен SEND относится ко всему набору продуктов, но governance нельзя описывать как полностью завершённое DAO. Текущая официальная документация по-прежнему говорит об upcoming SEND DAO и будущем revenue sharing. Контрактные адреса treasury опубликованы, однако наличие кошельков не равно активной системе голосования.

Основа Suilend

Suilend работает в Sui и использует объектную модель Move. Поставщики вносят актив в reserve, получают долевое представление депозита и зарабатывают процент от borrowers. Заёмщики объединяют collateral и debt в obligation, которая определяет health всей позиции.

Основные роли – suppliers, borrowers, liquidators, pool operators, oracle providers и protocol managers. В дополнительных продуктах появляются LST operators, liquidity providers и token launchers. Один пользователь может выполнять несколько ролей, но доход и риск каждой возникают из разных контрактов.

Main market

Большая часть ликвидности сосредоточена в main market. Он предназначен прежде всего для активов с глубокой on-chain liquidity и надёжными price feeds. Borrower может внести несколько поддерживаемых токенов и занять другие активы в пределах совокупной borrow limit.

Каждый reserve имеет loan-to-value, liquidation threshold, deposit and borrow limits, interest rate curve и reserve factor. Более высокий LTV повышает capital efficiency, но уменьшает запас до ликвидации. Добавление одного слабого collateral в общий рынок потенциально влияет на весь пул, поэтому listings и caps являются важной частью управления риском.

Откуда берётся доход

Borrowers платят процент за использование ликвидности. Borrow APR меняется по кривой utilization: при большом свободном остатке ставка ниже, при дефиците – выше. Supplier получает borrow interest, умноженный на utilization, за вычетом interest rate spread протокола.

Текущая документация Suilend указывает стандартный spread 20% от borrow interest. Это часть начисленного процента, а не 20% от депозита. Market incentives в SUI, SEND или другом токене могут добавляться отдельно и не являются постоянным свойством lending yield.

Процент начисляется во времени, но показанный APR меняется вместе со спросом. При utilization 100% бухгалтерское начисление продолжается, однако свободных токенов для withdrawal нет. Выход станет возможен после repayment, liquidation или нового supply.

Borrowing power и health

Oracle переводит каждый deposit и debt в сопоставимую стоимость. Borrow limit использует LTV, а liquidation threshold задаёт более высокий предел, после которого позицию разрешено закрывать. Разница между ними создаёт защитный буфер.

Interest увеличивает долг, поэтому health ухудшается даже без движения цены. Одновременное падение collateral и рост borrowed asset ускоряют процесс. В looping strategies небольшое начальное изменение может усиливаться несколькими уровнями займа.

Oracles

Suilend использует feeds Pyth и Switchboard. От них зависят account health и liquidation. Pyth Network публикует цены через модель first-party data providers и on-demand updates, но интеграция всё равно должна проверять freshness и confidence interval.

Два oracle provider не означают автоматическое усреднение каждой цены. Конкретный reserve может использовать определённый источник и fallback rules. Ошибка feed, задержка update, неверная конфигурация или реальный разрыв ликвидности способны вызвать bad debt или неправомерную ликвидацию.

Ликвидации

Когда obligation пересекает liquidation threshold, сторонний liquidator погашает часть долга и получает эквивалент collateral плюс bonus. Текущая пользовательская документация описывает стандартный сценарий с погашением 20% займа и 5% bonus. Фактические параметры следует сверять для конкретного market, поскольку pool configuration может меняться.

Liquidator должен получить и реализовать collateral. При резком падении или тонком рынке выручки может не хватить для полного покрытия. В main pool исторические bad debts могли закрываться из insurance addresses, но это дискреционный защитный ресурс, а не договорная гарантия.

Isolated markets

Новые, волатильные или менее ликвидные активы размещаются в отдельных pools. Их deposits, borrows и bad debt не должны смешиваться с main market. Pool operator может настроить curves, LTV и caps под конкретный риск.

Изоляция ограничивает contagion, но внутри отдельного пула убыток остаётся реальным. Если insurance не предусмотрено и возникает underwater debt, loss socialization распределяет shortfall между участниками вместо ситуации, когда весь убыток достаётся последнему вкладчику. Такой механизм справедливее гонки на выход, но всё равно уменьшает claims suppliers.

Suilend Strategies

Strategies автоматизируют несколько действий: mint LST, supply, borrow, looping, adjustment и withdrawal. Пользователь видит одну позицию, а контракты выполняют цепочку операций. Доходность зависит от стратегии и может сочетать staking, lending incentives и leveraged spread.

Удобный интерфейс не устраняет плечо. Interest rate может вырасти, reward emissions – снизиться, а LST – отклониться от underlying. Автоматизация также добавляет routing и smart-contract risk. Net APR следует раскладывать на устойчивую базовую доходность и временные incentives.

SpringSui и sSUI

SpringSui – стандарт liquid staking в Sui. Базовый продукт sSUI представляет застейканный SUI и накапливает rewards через рост exchange rate. Holder не получает новые sSUI каждую эпоху: одна единица постепенно соответствует большему количеству SUI.

Ключевая особенность – instant unstaking. Архитектура использует возможности native staking objects Sui, чтобы redemption не зависел от обычного ожидания нескольких эпох в том же виде, как у многих LST. Операция всё равно зависит от контракта, его reserve logic и применимой redemption fee.

SpringSui позволяет другим командам permissionlessly выпускать собственные LST. Operator выбирает validator strategy и fees в допустимых рамках. Поэтому свойства sSUI нельзя автоматически переносить на каждый токен стандарта: отличаются валидаторы, spread fee, mint and redemption configuration.

STEAMM

STEAMM – superfluid AMM, который направляет незадействованную часть pool liquidity в Suilend. При этом активы должны оставаться доступными для swaps. LP получает trading fees и потенциальный lending yield на idle capital, а routing между AMM и money market выполняется контрактами.

Продукт стартовал в beta в феврале 2025 года. К 2026 году документация описывает действующие pools, launcher и integrations, поэтому его нельзя называть только будущим планом. Однако каждый pool использует выбранный quoter и параметры, а beta-история остаётся важна для понимания зрелости.

STEAMM поддерживает три pricing mechanisms. CPMM использует обычное произведение резервов. vCPMM создаёт virtual reserve и позволяет запускать одностороннюю ликвидность. OMM опирается на oracle price и dynamic fee, что подходит для пар, где reserve ratio не должен быть единственным источником цены.

Из swap fee 20% направляется протоколу, остальные 80% – LP. Это доли конкретной комиссии пула, а не 20% от оборота. LP принимает impermanent loss, oracle risk в OMM, utilization risk Suilend и сложность одновременного AMM and lending accounting.

Token Launcher

Launcher создаёт Sui token и initial STEAMM pool. Issuer задаёт supply, quote asset, начальное распределение и может сделать token non-mintable или уничтожить LP tokens. Burning LP уменьшает риск немедленного изъятия initial liquidity, но не проверяет качество проекта и не запрещает другим holders продавать токен.

Permissionless launch расширяет набор активов, одновременно увеличивая риск мошеннических и неликвидных pools. Пользователь должен проверять coin type, mint abilities, ownership and pool settings. Появление актива в aggregator не означает endorsement.

Токен SEND

Общее предложение SEND – 100 млн. На community выделено 65%, investors – 20%, team – 15%. Investor allocation разблокируется в течение двух лет, team – четырёх. Большая community доля включает initial distributions и дальнейшие ecosystem incentives.

40% предложения распределялось через mdrop: 20% early users and points holders, 5% ecosystem communities и 15% holders SAVE в Solana. mSEND служил промежуточным claim asset. Ранний обмен на SEND требовал penalty в SUI, которая линейно снижалась к maturity.

Mdrops были механизмом конкретных распределений 2024–2025 годов. Сроки отдельных series и claim windows уже прошли или различаются. Их нельзя описывать как постоянно доступный способ получить SEND. Secondary buyer обычно приобретает сам SEND, а не право на старую allocation.

Управление

SEND позиционируется как governance token Suilend, SpringSui и STEAMM. Опубликованы адреса кошельков будущего DAO. Однако текущая документация всё ещё формулирует governance и revenue sharing как upcoming functions и не предоставляет завершённое описание active proposal, quorum and execution contracts.

Следовательно, владение SEND сейчас не следует приравнивать к полностью исполняемому on-chain контролю. Практические решения по listings, isolated pools, risk parameters и deployments сохраняют значительную роль core team и pool operators. Если DAO будет активирован, оценка должна опираться на deployed contracts, а не старый roadmap.

История

Suilend создала команда Solend, позднее переименованного в Save. Опыт кредитования в Solana был перенесён в Move-архитектуру Sui. Mainnet Suilend запустился в марте 2024 года.

В октябре 2024 года появился SpringSui, в декабре состоялся TGE SEND и начались mdrop distributions. В феврале 2025 года STEAMM вышел в beta, затем получил main product integrations и Token Launcher. К 2026 году экосистема включает main and isolated lending, strategies, liquid staking и несколько типов AMM pools.

Команда

Официальные материалы называют разработчиков командой Save, ранее Solend. Проект не поддерживает на текущей странице стабильный поимённый roster, поэтому приписывать действующие должности людям из старых материалов Solend ненадёжно.

Suilend сообщал о поддержке Robot Ventures, Delphi Ventures, DeFi Alliance, Mechanism Capital и Karatage, а также отдельных angel investors. Финансирование и опыт команды снижают execution risk, но не страхуют deposits. Управление контрактами, audits и incident response важнее списка инвесторов.

Основные риски

  • Smart contract risk. Lending, SpringSui, Strategies и STEAMM образуют связанную, но неоднородную систему.
  • Oracle risk. Pyth или Switchboard feed влияет на health и liquidation.
  • Utilization risk. При полном использовании reserve withdrawal временно невозможен.
  • Liquidation risk. Interest, volatility и leverage способны быстро уничтожить safety buffer.
  • Isolated-pool risk. Слабый collateral может привести к socialized loss внутри пула.
  • LST risk. sSUI и сторонние SpringSui tokens зависят от validators, fees и redemption contracts.
  • AMM risk. STEAMM добавляет impermanent loss, quoter и routing risk к lending exposure.
  • Governance risk. SEND DAO нельзя считать полностью работающим до появления проверяемого execution process.
  • Token risk. Unlocks, ecosystem emissions и прошлые mdrop penalties влияют на обращение SEND.

Итог

Suilend превращает lending liquidity в основу нескольких продуктов Sui. Main market обслуживает крупные активы, isolated pools ограничивают риск новых токенов, SpringSui делает stake переносимым, а STEAMM повторно задействует свободную AMM liquidity.

Интеграция повышает capital efficiency, но связывает риски. Ошибка oracle влияет на lending, дефицит liquidity – на withdrawal, LST deviation – на collateral, а AMM – на стоимость LP position. SEND объединяет экономику экосистемы, однако governance следует считать формирующимся, пока active DAO contracts и правила исполнения не подтверждены.