Rebase-криптовалюта: как работает elastic supply и почему меняется баланс токенов

Rebase-криптовалюта — это токен с эластичным предложением, у которого протокол может пропорционально увеличивать или уменьшать количество единиц на кошельках держателей. Пользователь способен открыть кошелёк после очередного перерасчёта и увидеть другой баланс, хотя сам ничего не отправлял и не получал. Такое изменение называется rebase. Оно не является обычной транзакцией между двумя людьми, не обязательно означает доход и не должно автоматически трактоваться как начисление процентов.

Главная идея rebase-механики — перенести часть волатильности из цены в количество единиц. У обычного токена спрос меняется, а число монет на кошельке остаётся прежним; цена реагирует на рынок. У elastic-supply токена протокол дополнительно меняет supply по определённому правилу. Если политика устроена пропорционально, доля держателя в общей сети после rebase остаётся примерно той же: у всех подходящих адресов количество единиц меняется одним коэффициентом.

Из-за этого rebase легко понять неправильно. Положительный rebase, при котором баланс вырос на 10%, не равен гарантированной прибыли 10%. Отрицательный rebase не означает, что кто-то забрал у пользователя деньги. Нужно смотреть одновременно на количество токенов, цену одной единицы, общую стоимость позиции, долю в supply, ликвидность и правила протокола. Только такая картина показывает экономический результат.

Классический пример elastic supply — AMPL: официальная документация описывает актив, у которого при отклонении цены от целевой области количество токенов на адресах пропорционально увеличивается или уменьшается. Но здесь AMPL используется только как технический пример. Цель статьи — дать универсальную методику анализа любого rebase-токена: от формулы supply adjustment и oracle до wrappers, DeFi-интеграций и учёта.

Если вы анализируете неизвестный токен, rebase нельзя рассматривать отдельно от контракта, ликвидности, прав администратора и токеномики. Сначала полезно пройти базовую проверку по материалу OneMagic о том, как проверить токен перед покупкой, а затем отдельно разобрать elastic-supply механику по правилам ниже.

Rebase меняет число единиц, а не обещает доходность. Экономический результат определяется стоимостью всей позиции после корректировки, а не размером нового баланса.

Что такое rebase в криптовалюте и чем он отличается от обычной эмиссии

Rebase меняет баланс пропорционально политике протокола

При обычной эмиссии новые токены создаются и кому-то назначаются: валидатору, фонду, пользователю программы стимулов или казначейству. Доля существующего держателя может размываться, если новые единицы получают другие участники. В пропорциональном rebase ситуация иная: коэффициент применяется ко всем учитываемым балансам одновременно, поэтому относительная доля владельца в supply сохраняется, если он не покупал и не продавал токены.

Представим сеть с total supply 1 000 000 токенов. Пользователь держит 10 000, то есть 1% предложения. После positive rebase supply увеличивается на 20% до 1 200 000, а баланс пользователя — до 12 000. Он по-прежнему владеет 1%. Получение дополнительных 2 000 единиц не сделало его богаче автоматически: если цена одной единицы одновременно снизилась пропорционально, стоимость позиции могла почти не измениться.

Positive rebase — расширение предложения

Положительный rebase увеличивает количество единиц. В моделях с ценовым таргетом он обычно используется, когда наблюдаемая цена устойчиво выше целевого уровня или другого управляющего ориентира. Идея заключается в том, чтобы увеличить supply и тем самым изменить экономические условия, которые могут способствовать возвращению цены к целевой области.

Важно слово «могут». Протокол не управляет покупателями и продавцами напрямую. Расширение предложения создаёт другой баланс scarcity, но рынок способен продолжать торговать выше таргета, если спрос остаётся сильным. Rebase — политика предложения, а не гарантированный арбитражный механизм, который мгновенно фиксирует цену.

Negative rebase — сокращение предложения

Отрицательный rebase пропорционально уменьшает число единиц на адресах. Если supply сокращается на 10%, кошелёк с 100 токенами может показывать около 90. Это психологически воспринимается тяжелее обычного падения цены, потому что пользователь видит уменьшение самого количества. Но доля в сети при пропорциональном механизме остаётся прежней.

Negative rebase не нужно путать с штрафом или списанием. У корректной elastic-supply модели это заранее описанная денежная политика. Пользователь принимает её, когда владеет активом. Экономический риск состоит в том, что одновременно с сокращением количества цена может не вырасти достаточно для сохранения общей стоимости позиции.

Neutral rebase означает отсутствие изменения

Если цена находится в допустимом диапазоне или политика использует порог отклонения, rebase может быть нейтральным. Тогда коэффициент равен единице и баланс остаётся прежним. Нейтральный период важен для анализа: он показывает, что система не обязана ежедневно менять supply просто ради активности.

У некоторых протоколов существует deviation threshold — зона, внутри которой небольшие отклонения не вызывают корректировку. Такой буфер уменьшает частоту микроскопических изменений и позволяет рынку колебаться вокруг цели. При анализе нужно знать не только target, но и ширину этой зоны.

Rebase не равен стейкингу

Стейкинг создаёт вознаграждение за участие в механизме сети или делегирование. Новые единицы начисляются конкретным участникам по правилам валидаторов и могут менять доли между теми, кто стейкает, и теми, кто не стейкает. Rebase меняет балансы по глобальной формуле. Это разные источники изменения количества токенов.

Если вы хотите сравнить их, используйте отдельный материал OneMagic о стейкинге, валидаторах и доходности. Особенно важно не называть positive rebase «процентом годовых»: баланс вырос по денежной политике, а не потому, что актив сгенерировал независимый денежный поток.

Rebase не равен stock split

В традиционных рынках split делит каждую единицу на большее число частей и пропорционально меняет цену, не меняя экономическую ценность компании. Rebase внешне похож на split только тем, что количество единиц у многих держателей меняется одновременно. Но rebase может происходить многократно и является активным элементом денежной политики, реагирующим на параметры рынка.

Кроме того, split обычно не пытается возвращать рыночную цену к целевому ориентиру через динамический supply. Поэтому аналогия полезна лишь для первого объяснения пропорциональности, но быстро становится неточной.

Как работает elastic supply: target price, oracle, epoch и коэффициент rebase

Target price — ориентир, а не гарантированная цена

Многие rebase-протоколы задают целевую стоимость единицы. Это может быть фиксированный ориентир, индексированная величина или другой показатель. Сам target не является обещанием выкупа токена по этой цене. Если нет механизма погашения с обеспечением, пользователь не может требовать у протокола обмен по target. Это принципиальное отличие от обеспеченных моделей.

Рынок может находиться выше или ниже цели. Rebase меняет supply в направлении, которое политика считает стабилизирующим, но цена остаётся результатом сделок между участниками. Поэтому фраза «токен привязан к доллару» для rebase-модели часто неверна: корректнее говорить о целевом ориентире денежной политики.

Oracle сообщает протоколу наблюдаемую цену

Чтобы решить, нужен ли rebase, контракту требуется внешняя информация о цене. Обычно её поставляет oracle-механизм: агрегированная цена, TWAP, VWAP или другая схема. От качества oracle зависит сама корректность денежной политики. Ошибочный отчёт способен вызвать нежелательное расширение или сокращение supply.

Проверяйте источник данных, период усреднения, число поставщиков, процедуру обновления и аварийные механизмы. Хорошая система не должна слепо доверять одной мгновенной котировке. В истории elastic-supply протоколов уже встречались инциденты, когда проблемы с oracle требовали временно нейтрализовать rebase. Это отдельный класс риска, который нельзя увидеть по графику цены токена.

Epoch задаёт момент пересчёта

Rebase часто выполняется по расписанию — например, раз в сутки или раз в другой период. Интервал называется epoch или rebase window в зависимости от реализации. Важно понимать, когда именно вычисляется коэффициент: перед снимком баланса, после него, по какому ценовому окну и в каком блоке.

Это имеет практическое значение для приложений, которые индексируют баланс, рассчитывают залог или ведут бухгалтерию. Если сервис обновляет данные реже rebase, пользователь может временно видеть старое количество. Ошибка интерфейса не обязательно означает, что токены исчезли.

Deviation threshold защищает от слишком мелких корректировок

Если цена отличается от target на доли процента, постоянный rebase может создавать технический шум. Поэтому политика может использовать порог: пока отклонение находится внутри допустимого диапазона, изменение supply равно нулю. За пределами диапазона включается положительная или отрицательная корректировка.

Инвестору нужно знать точное правило. Два токена с одинаковым target могут вести себя совершенно по-разному, если у одного threshold 2%, у другого 10%, а третий использует непрерывную кривую без жёсткой границы.

Reaction lag сглаживает корректировку

Протокол не обязан изменять supply на всю величину ценового отклонения сразу. Reaction lag или аналогичный параметр растягивает adjustment во времени. Если цена выше цели на 20%, система может увеличить предложение только на часть этого отклонения в текущем epoch, а затем повторно оценить ситуацию.

Сглаживание снижает риск резких скачков количества и даёт рынку время реагировать. Но одновременно путь к target становится более медленным. Чем агрессивнее rebase curve, тем сильнее изменение баланса за один шаг и тем выше требования к интеграциям.

Глобальный scalar позволяет менять миллионы балансов без миллионов транзакций

Наивная реализация rebase требовала бы пройти по всем адресам и изменить каждый баланс, что технически невозможно и чрезвычайно дорого. Поэтому elastic-supply токены обычно используют внутреннее представление: доли, shares, gons или другой фиксированный учёт плюс глобальный коэффициент. Видимый баланс вычисляется через этот коэффициент.

Когда rebase меняет scalar, экономический баланс каждого адреса меняется логически, хотя по сети не проходит отдельная transfer-транзакция для каждого владельца. Именно поэтому пользователь может увидеть новое количество без входящей операции в истории.

Пропорциональность — ключ к недилютивному rebase

Если корректировка применяется одинаково, доля пользователя в supply остаётся постоянной. Формально можно представить: new_balance = old_balance × rebase_factor и new_supply = old_supply × rebase_factor. Отношение new_balance / new_supply совпадает со старым отношением.

Это не делает актив безрисковым. Недилютивность защищает долю от самого rebase, но не от цены, ликвидности, изменения протокола, ошибок контракта или выпуска других классов токенов.

Почему баланс rebase-токена меняется без обычной транзакции

Explorer может не показывать входящий transfer

Самая частая тревога новичка возникает после negative rebase: баланс уменьшился, но в истории нет исходящей транзакции. Это нормально для глобального scalar-механизма. Никто не подписывал перевод от имени пользователя; контракт пересчитал, сколько видимых единиц соответствует его внутренней доле. Увеличение после positive rebase устроено так же: дополнительные units появляются не потому, что неизвестный адрес прислал перевод.

Поэтому привычный список transfer-событий недостаточен для восстановления истории rebase-позиции. Нужно смотреть rebase event, изменение total supply и коэффициент, который применил протокол. Хороший блокчейн-эксплорер или специализированный dashboard показывает эти события отдельно, но при самостоятельной проверке важнее уметь получить данные из контракта.

Нужно хранить историю rebase-событий

Для точного учёта полезно сохранять дату, номер блока, коэффициент rebase, supply до и после, собственный баланс до и после и ориентировочную рыночную цену. Это позволяет отделить изменение количества от покупки, продажи, перевода или вознаграждения другой природы. Без такого журнала через год сложно объяснить, почему на кошельке другое число токенов, хотя число собственных транзакций невелико.

Если протокол публикует событие LogRebase или аналог, индексатор может построить историю автоматически. При значительных суммах не полагайтесь на единственный интерфейс: сохраните TxID или block number, чтобы позже независимо воспроизвести расчёт.

Стоимость позиции считается как баланс × цена

Допустим, до rebase у вас 1 000 токенов по $1,20 — позиция стоит $1 200. После positive rebase +10% баланс стал 1 100. Если цена одновременно опустилась до $1,09, стоимость около $1 199. Количество выросло, но экономического выигрыша почти нет. Если цена осталась $1,20, позиция стала дороже; если упала сильнее, итог отрицательный.

И наоборот, после negative rebase −10% баланс становится 900. Если цена выросла до $1,33, стоимость около $1 197. Поэтому оценивать только число единиц бессмысленно. Всегда сравнивайте общую стоимость, долю supply и доступную ликвидность, по которой эту стоимость реально можно реализовать.

Wallet может кэшировать старый баланс

Некоторые кошельки и портфельные трекеры рассчитывают balance через индексатор, который обновляется с задержкой. После rebase интерфейс может временно показывать старое значение, ноль или расхождение между приложениями. Это интеграционная проблема, а не обязательная потеря средств. Особенно часто задержки заметны сразу после крупного supply adjustment.

Проверяйте баланс через несколько независимых источников и напрямую через контракт. Если адрес и сеть верны, RPC-вызов balanceOf или аналогичный метод помогает отделить проблему интерфейса от реального состояния. Никогда не вводите seed-фразу на случайном сайте ради «синхронизации rebase»: баланс не восстанавливается передачей секретной фразы стороннему сервису.

Cost basis становится сложнее

Rebase меняет число единиц без классической покупки. Если пользователь пытается считать среднюю цену простым делением «сколько заплатил / сколько токенов сейчас», она будет постоянно меняться после каждого adjustment. Для управленческого анализа это может быть полезно, но для налогового или бухгалтерского учёта правила зависят от юрисдикции и квалификации самого rebase-события.

Сохраняйте первоначальные операции приобретения и отдельную историю supply adjustments. Не пытайтесь задним числом восстановить всё только по текущему балансу. При значительных суммах вопрос налоговой квалификации rebase требует актуальной профессиональной проверки на дату отчётности: старое разъяснение может не учитывать конкретную механику вашего токена.

Transfer amount и экономическая доля — не одно и то же

Если вы отправили другому человеку 100 rebase-токенов сегодня, после будущих корректировок у получателя может быть другое количество. Экономический смысл такого обязательства зависит от того, что стороны считают предметом расчёта: фиксированные units, долю сети или стоимость около target. Для обычных платежей это важное отличие от fixed-supply актива.

Именно поэтому elastic-supply токены сложнее использовать в договорах и учётных системах, где предполагается, что 100 единиц остаются 100 единицами до следующей транзакции. Приложение должно понимать динамический balance, иначе отчётность начнёт расходиться с блокчейном.

Wrapped-версия решает проблему меняющегося количества

Один из распространённых подходов — обернуть rebase-токен в non-rebasing wrapper. Пользователь блокирует elastic token и получает фиксированное количество wrapped-токенов. Баланс wrapper не меняется при rebase; вместо этого меняется количество базового актива, которое соответствует одной wrapped-единице. Экономическая экспозиция сохраняется, но интерфейс становится привычнее.

Официальная документация Ampleforth описывает WAMPL именно как non-rebasing форму, полностью погашаемую в AMPL on-chain. Такой дизайн удобнее для систем, которые ожидают обычный ERC-20 с фиксированным балансом. Но wrapper добавляет отдельный смарт-контрактный слой: проверяйте код, права upgrade, ликвидность и процедуру unwrap.

Цена, market cap и доля владельца: как правильно считать результат rebase

Положительный rebase не создаёт капитал из воздуха

Если всем держателям увеличить количество токенов в одинаковой пропорции, доля каждого не изменится. При неизменном market cap теоретическая цена одной единицы должна снизиться обратно пропорционально supply. На реальном рынке market cap не фиксирован, поэтому цена может вести себя иначе, но сама арифметика показывает, почему рост баланса не является бесплатной прибылью.

Считать positive rebase как yield — одна из главных ошибок. Доходность существует только если общая стоимость позиции выросла относительно выбранной базы. Например, если balance увеличился на 25%, но price снизилась на 30%, владелец получил больше units и одновременно потерял в денежной стоимости.

Negative rebase тоже не равен фиксированному убытку

Сокращение units выглядит как потеря, но если цена одной единицы увеличилась сильнее, общая стоимость способна вырасти. Конечно, такой рост не гарантирован. Поэтому negative rebase создаёт специфическую психологическую нагрузку: человек видит меньше монет и может панически продавать, не оценивая value позиции.

Управление риском строится вокруг стоимости капитала, ликвидности и допустимой просадки, а не вокруг количества токенов. Важно заранее принять, что число units — переменная, а не якорь.

Ownership share — самая стабильная метрика внутри чистого rebase

Для пропорциональной модели удобно отслеживать долю: balance / total supply. Если протокол честно применяет один factor ко всем, отношение остаётся примерно постоянным. Это помогает проверить, действительно ли rebase недилютивный. Если вы владели 0,5% сети до adjustment, в нормальной модели останетесь около 0,5% после него.

Если доля неожиданно изменилась без вашей транзакции, выясните причину: адрес исключён из механизма, часть supply обрабатывается иначе, существует wrapper, контракт обновлён или индексатор считает данные некорректно. Изменение ownership — более серьёзный сигнал, чем простое изменение units.

Market cap может меняться и из-за цены, и из-за supply

Капитализация определяется как цена × circulating supply по методике источника. У rebase-токена обе части уравнения способны изменяться одновременно. Поэтому график market cap иногда информативнее одного графика цены: он показывает изменение совокупной рыночной оценки, а не только стоимость одной elastic unit.

Чтобы не путать эти показатели, используйте материал OneMagic о market cap, circulating supply и FDV. Особенно внимательно проверяйте, как агрегатор считает supply после rebase и нет ли задержки в обновлении.

FDV у elastic supply требует осторожности

Полностью разводнённая оценка предполагает некоторый будущий или максимальный supply. Но у elastic-supply модели количество может динамически расширяться и сокращаться; фиксированный max supply либо отсутствует, либо не отражает экономическую политику так же, как у обычного токена. Поэтому FDV может быть менее содержательной метрикой.

Если источник показывает FDV, прочитайте методику. Иногда он использует current supply, иногда технический cap, иногда максимально возможное значение контракта. Сравнение такого FDV с fixed-supply токеном способно создавать ложное ощущение дешёвой или дорогой оценки.

Цена около target — не доказательство устойчивости

Даже если rebase-токен долго торгуется около цели, нужно понять, почему. Стабильность может быть следствием рыночного спроса, арбитража, ликвидности, периода низкой волатильности или параметров policy. История вокруг target не является гарантией будущего поведения.

Риск-модель должна включать сценарий длительного отклонения: что происходит с supply, ликвидностью и поведением пользователей, если цена остаётся ниже цели неделями или месяцами? Если система теряет ликвидность быстрее, чем contraction меняет scarcity, target может оставаться недостижимым.

Сравнивайте общую стоимость до и после серии rebase

Правильная таблица содержит дату, units, price, portfolio value, total supply и ownership share. Тогда видно, что произошло за месяц: изменилось ли состояние из-за рынка, rebase или собственных сделок. Такой журнал позволяет анализировать не один красивый positive rebase, а всю траекторию.

Он же помогает сравнить rebase-токен с альтернативой. Можно посчитать total return простого holding wrapper или другого актива за тот же период, не смешивая units и стоимость.

Rebase-токены в DeFi: AMM, пулы ликвидности, lending и wrappers

AMM должен корректно переживать изменение балансов

Автоматический маркет-мейкер рассчитывает цену по резервам пула. Если один из токенов внезапно меняет баланс из-за rebase, стандартные предположения протокола могут нарушиться. Некоторые AMM умеют корректно работать с elastic supply, другие требуют wrapper или специальную интеграцию. Ошибка не обязательно проявится при первом депозите — она может стать заметной только после следующего rebase.

Перед внесением ликвидности проверьте документацию конкретного пула. Сам факт, что интерфейс позволяет внести токен, не гарантирует корректный учёт. Нужна явная поддержка elastic balance или доказанная wrapper-модель.

LP-позиция усложняет понимание ownership

Когда токены находятся в пуле, пользователь больше не держит их напрямую на своём адресе: он владеет долей LP. Rebase меняет резервы контракта, а эффект распределяется через структуру пула. Простая формула «мой wallet balance вырастет» здесь уже не работает.

Нужно смотреть, как AMM учитывает изменение reserve, кто получает дополнительный supply и как меняется цена после синхронизации. Иногда LP contract сам становится адресом, к которому применяется rebase, а пользователь получает эффект через стоимость LP-share.

Impermanent loss накладывается на supply volatility

LP уже несёт риск относительного движения цен. Rebase добавляет изменение количества и может усложнить сравнение с простой стратегией hold. Поэтому итог LP нужно сравнивать с контрольным портфелем, который тоже переживал бы те же rebases. Иначе пользователь приписывает rebase результат, который на самом деле возник из-за AMM-ребалансировки.

Отдельный материал OneMagic об impermanent loss помогает правильно построить baseline. Считайте fees, incentives, gas, supply adjustment и стоимость контрольного портфеля отдельно.

Пул с rebase требует анализа активной ликвидности

Большой TVL пула не гарантирует, что rebase-токен можно продать крупным объёмом без price impact. Резервы могут быть концентрированными, часть ликвидности — вне диапазона, а после rebase ценовые соотношения меняются. Номинальная цифра TVL не отвечает на вопрос об исполнимости вашей сделки.

Смотрите на реальную глубину и модель пула. Для базовой проверки используйте статьи OneMagic о пулах ликвидности и о ликвидности криптовалюты.

Lending-протокол должен понимать меняющийся collateral

Если rebase-актив используется как залог или объект займа, протокол обязан корректно учитывать supply adjustment. Positive rebase меняет количество underlying, negative — уменьшает его. Неправильная интеграция может исказить health factor, начисления, доступный collateral и условия ликвидации.

Некоторые системы используют wrapper, shares или специальный adapter. Если документация lending-протокола не описывает rebase явно, лучше не предполагать совместимость только потому, что депозит проходит технически.

Wrapped rebase-токен упрощает интеграцию

Non-rebasing wrapper переводит supply volatility в цену wrapped-единицы. Пользователь держит фиксированное количество wrapper, а его redeemable amount базового токена меняется. Это удобнее для протоколов, где balance должен оставаться постоянным и где share accounting построен вокруг обычного ERC-20.

Но wrapper создаёт дополнительный риск смарт-контракта и ликвидности. Проверяйте возможность on-chain redemption, code, права upgrade и фактическую глубину рынка wrapper. Нельзя считать wrapper безрисковым только потому, что он скрывает rebase от интерфейса.

Bridges требуют отдельной логики

Мост обычно блокирует актив в одной сети и выпускает representation в другой. Если underlying rebase меняется, bridge должен решить, как передать эффект владельцам bridged-версии. Простая модель 1:1 может стать некорректной, если lock-контракт получил positive rebase, а representation supply не изменился.

Поэтому elastic tokens часто используют wrappers перед bridge. Пользователь должен понимать, чем именно он владеет после переноса: native elastic asset, fixed wrapper или synthetic representation. Эти формы могут иметь разные contract address, liquidity и redemption path.

Vault может скрывать rebase от пользователя

Стратегический vault способен принимать rebase-токен и выдавать shares. Тогда пользователь видит постоянное число shares, а value per share меняется вместе с underlying и доходностью стратегии. Это удобнее интерфейсно, но делает анализ сложнее.

Проверяйте бухгалтерию vault: как rebase влияет на NAV, когда производится harvest, есть ли management/performance fees и как рассчитывается redemption. Нельзя просто прибавить positive rebase к заявленной доходности vault — это может быть двойной счёт.

Главные риски rebase-криптовалюты: что может пойти не так

Oracle risk напрямую влияет на supply

У обычного токена ошибка ценового oracle может навредить внешнему DeFi-приложению, но не обязательно изменит сам supply. В rebase-модели oracle часто является частью денежной политики. Неверная цена способна инициировать неправильное расширение или сокращение предложения, то есть затронуть все балансы одновременно. Поэтому oracle risk здесь ближе к системному риску самого актива.

Проверяйте, откуда берётся цена, как долго она усредняется, какие источники допускаются, есть ли fallback, задержка обновления и emergency mode. Если протокол использует один поставщик без резервного канала, денежная политика зависит от одной точки отказа. Если используется несколько источников, изучите правило агрегации и процедуру исключения аномальных данных.

Stale data опасны не меньше манипуляции

Oracle может не быть взломан, но перестать обновляться вовремя. Тогда policy получает формально корректное, но устаревшее значение. Хорошая архитектура проверяет timestamp и отказывается применять rebase при слишком старых данных. Пользователю стоит найти такой safeguard в коде или документации.

Если протокол в истории уже сталкивался с oracle incident, полезно изучить, что произошло: был ли rebase нейтрализован, существовал ли security delay, кто принял решение и как быстро система восстановилась. Поведение команды и governance во время реального сбоя даёт больше информации, чем маркетинговая страница.

Smart-contract risk затрагивает глобальный scalar

Ошибка в математике rebase способна повлиять на все балансы одновременно. Особенно опасны неверные ограничения supply, ошибки округления, неправильная обработка экстремального коэффициента, доступ к policy-функции неавторизованного адреса и несовместимость после upgrade. Поскольку один scalar может масштабировать огромный объём токенов, баг имеет системный эффект.

Аудит снижает риск, но не устраняет его. Смотрите, сколько времени конкретная версия контракта работает без изменений, насколько часто обновляется policy, есть ли formal verification, bug bounty и публичные post-mortem. Новый upgrade фактически создаёт новую поверхность риска даже у старого проекта.

Governance может изменить экономические правила

Elastic supply обычно имеет параметры: target, deviation threshold, rebase curve, oracle, период epoch. Если governance может менять их, инвестор покупает не только текущую формулу, но и процесс будущих решений. Политика с reaction lag 10 сегодня может стать более агрессивной завтра; symmetric curve может стать asymmetric; oracle provider может быть заменён.

Проверьте timelock, кворум, концентрацию голосов и emergency powers. Чем быстрее небольшая группа способна изменить policy, тем больше управленческий риск. Децентрализованное голосование тоже не гарантирует хорошего решения, но даёт пользователю больше времени и прозрачности для оценки изменений.

Liquidity risk усиливает negative rebase

Когда баланс уменьшается, часть держателей может одновременно захотеть выйти. Если liquidity слабая, negative rebase сопровождается slippage и дополнительным падением цены. Теоретическая недилютивность не спасает от невозможности продать объём. В стрессовый момент именно depth определяет, можно ли превратить расчётную стоимость в реальные деньги.

Перед покупкой оцените spread, depth на нескольких уровнях, историю объёма и концентрацию LP. Если большая часть ликвидности зависит от одной стимулирующей программы, она может исчезнуть одновременно с падением спроса.

Reflexivity делает поведение сложнее простой формулы

Rebase пытается воздействовать на предложение, но ожидания участников меняют спрос. Positive rebase может привлекать покупателей, которые ошибочно воспринимают рост units как yield; это повышает цену и приводит к новым расширениям. Получается рефлексивный цикл, который внешне выглядит устойчивым, пока приток спроса продолжается.

В обратную сторону negative rebase способен усиливать страх. Баланс уменьшается, пользователи продают, price pressure сохраняется, contraction повторяется. Математическая policy может быть неизменной, но поведение людей делает траекторию нелинейной. Поэтому нельзя прогнозировать цену из одной формулы supply.

Integration risk проявляется неожиданно

Кошелёк, бухгалтерский сервис, bridge, lending-протокол, vault или кастодиальный софт может предполагать fixed balance. Rebase нарушает это предположение. Ошибка интеграции иногда не видна до первого крупного adjustment: до этого все операции проходят, а после rebase часть системы использует старое значение.

Используйте только приложения, где поддержка elastic token описана явно. Если интерфейс принимает токен, но документация молчит о rebase, это не доказательство безопасности. Для сложной интеграции лучше использовать официальный wrapper, если он предусмотрен архитектурой.

Tax и accounting risk нельзя решить универсальным советом

В разных юрисдикциях увеличение или уменьшение баланса без обычной транзакции может трактоваться по-разному. Некоторые системы налогообложения ориентируются на экономическую реализацию, другие могут рассматривать событие получения дополнительных units иначе. Правила меняются и редко написаны специально для rebase-механики.

Сохраняйте историю каждого rebase, balance до и после, рыночную стоимость и первичные документы покупки. При значительной позиции обратитесь к специалисту, который понимает цифровые активы. Попытка восстановить год ежедневных rebases задним числом только по текущему балансу создаёт высокий риск ошибки.

Target risk: целевая цена может потерять экономический смысл

Если target связан с внешним индексом, CPI или другой величиной, нужно понимать, как этот показатель обновляется и почему участники продолжают считать его полезным. Даже технически корректный rebase не делает target экономически значимым автоматически. Если пользователи не хотят держать актив по этой логике, supply adjustment не создаёт спрос из ничего.

Отдельно проверьте, есть ли у target mechanism redemption или только policy signal. Актив без обязательного погашения по target может торговаться далеко от ориентира длительное время.

Wrapper risk добавляется поверх базового протокола

Non-rebasing wrapper делает баланс понятнее, но создаёт второй контракт. У пользователя появляется риск ошибки wrap/unwrap, upgradeability, неправильного exchange rate, блокировки redemption или недостаточной ликвидности wrapper. Нельзя считать wrapped-форму безопаснее базовой только потому, что количество units не меняется.

Сильный wrapper должен быть прозрачно обеспечен underlying, иметь понятную формулу redemption и возможность проверить резервы on-chain. Если wrapper использует дополнительные посредники, мосты или custodial layer, риск становится выше.

Как проверить rebase-токен перед покупкой: технический и экономический аудит

Шаг 1. Найдите точный contract address

Начните с адреса контракта и официальной документации. Не анализируйте тикер: одинаковое название может использовать другой токен. Contract address должен совпадать в нескольких независимых официальных источниках. Если проект мигрировал, выясните, какая версия является актуальной и что произошло со старой.

Проверка адреса, ownership и proxy подробно разобрана в материале OneMagic про проверку токена до покупки. Для rebase это особенно важно, потому что policy contract иногда отделён от самого token contract.

Шаг 2. Найдите официальный policy document

Документация должна отвечать на пять вопросов: какой target используется, какой oracle передаёт цену, когда происходит epoch, какой deviation threshold действует и как рассчитывается rebase rate. Если проект описывает механику словами «алгоритм стабилизирует цену» без формулы и параметров, анализировать риск практически невозможно.

Хорошая документация также объясняет edge cases: что происходит при extreme deviation, stale oracle, paused policy, max supply и governance update. Эти детали важнее красочной схемы.

Шаг 3. Проверьте историю total supply

Постройте график total supply минимум за несколько месяцев. Найдите positive, negative и neutral периоды. Сравните их с price относительно target. Policy должна вести себя так, как описано. Если price ниже threshold, а supply расширяется, нужно понять причину.

Историческое соответствие не гарантирует будущее, но помогает проверить, что механизм не является просто маркетинговым названием. Для каждого крупного отклонения найдите event и block, где был применён adjustment.

Шаг 4. Рассчитайте ownership share

Возьмите адрес, который не совершал transfers между двумя rebases, и сравните balance / totalSupply до и после. Отношение должно быть устойчивым в недилютивной модели. Лучше провести такой тест на positive и negative adjustment.

Если доля меняется, найдите техническое объяснение. Возможно, токен имеет excluded addresses, treasury handling или special accounts. Такая особенность должна быть отражена в документации.

Шаг 5. Разберите oracle как отдельную систему

Узнайте, какая цена используется: spot, TWAP, VWAP, медиана нескольких источников. Как часто обновляется? Какой heartbeat? Есть ли security delay? Кто может заменить provider? Как протокол реагирует на stale data и extreme outlier?

Oracle — не вспомогательный компонент. Для rebase это один из входов monetary policy. Инвестор должен понимать его не хуже, чем сам token contract.

Шаг 6. Проверьте rebase curve

Некоторые политики используют линейный reaction lag, другие — sigmoid или piecewise curve. Важно оценить максимальный positive и negative adjustment за один epoch. Чем круче curve, тем сильнее balance shock и выше интеграционный риск.

Постройте простую таблицу: price deviation −50%, −20%, −10%, +10%, +20%, +50% и ожидаемый rebase. Если вы не можете это посчитать по документации, правила недостаточно прозрачны.

Шаг 7. Изучите admin roles и governance

Найдите owner, proxy admin, policy setter, oracle admin, timelock и governance contract. Проверьте, может ли одна сторона менять target, threshold, curve, epoch или исключать адреса. Чем больше полномочий у одного ключа, тем выше policy risk.

Если contract upgradeable, определите задержку между governance decision и активацией. Пользователь должен иметь время выйти, если правила фундаментально меняются.

Шаг 8. Проверьте wrapper

Если экосистема предлагает wrapped-версию, определите conversion formula. Сколько underlying соответствует одному wrapper? Как меняется exchange rate после rebase? Можно ли всегда unwrap on-chain? Есть ли fee, pause, cap или whitelist?

Сравните contract code и официальную документацию. Wrapper с фиксированным supply часто удобнее для DeFi, но он не должен скрывать непонятное обеспечение.

Шаг 9. Проверьте liquidity двух форм

Базовый elastic token и wrapper могут иметь разную market depth. Иногда wrapper намного удобнее для торговли и DeFi, а native token используется как unit of account. В других проектах ликвидность сосредоточена в базовой форме.

Сделайте отдельный price-impact test для каждой формы на свою плановую сумму. Нельзя экстраполировать ликвидность одного контракта на другой.

Шаг 10. Проверьте integrations

Составьте список: wallet, AMM, lending, bridge, vault, portfolio tracker. Для каждого найдите официальное подтверждение поддержки elastic balance или wrapper. Не полагайтесь на старую публикацию: интеграция могла быть отключена после update.

Если приложение использует rebase-токен как collateral, особенно внимательно изучите liquidation logic и accounting shares.

Шаг 11. Смоделируйте длительный contraction

Самый полезный стресс-тест — не один negative rebase, а серия. Допустим, supply сокращается на 2% ежедневно десять дней, price остаётся ниже target и liquidity падает. Что происходит с вашей position value и возможностью выхода?

Если стратегия выдерживает только быстрый возврат к target, вы фактически делаете ставку на поведение рынка, а не на сам протокол.

Шаг 12. Сравните с простой альтернативой

Спросите, зачем вам нужен именно elastic-supply exposure. Может ли fixed-supply asset, wrapper или другой инструмент решать ту же задачу с меньшей сложностью? Дополнительный механизм оправдан только реальной функцией.

Сложность — это стоимость: больше параметров, больше контрактов, больше способов ошибиться.

1. Проверить contract и policy document.
2. Зафиксировать target, oracle, threshold, epoch и curve.
3. Сравнить исторический supply с rebase events.
4. Проверить ownership share до и после.
5. Изучить oracle и stale-data protection.
6. Посчитать rebase rate при разных deviations.
7. Проверить admin roles, proxy и timelock.
8. Проверить wrapper и redemption.
9. Оценить liquidity базового токена и wrapper.
10. Проверить DeFi-интеграции.
11. Построить stress test negative rebases.
12. Сравнить сложность с альтернативой.

Техническая реализация rebase: shares, gons, scaling factor и события контракта

Почему нельзя просто переписать balance каждого адреса

Блокчейн не умеет бесплатно пройти по миллионам держателей и записать новый баланс каждому при одном rebase. Любой цикл по неизвестному количеству адресов упёрся бы в gas limit и стоимость исполнения. Поэтому rebase-token хранит состояние иначе, чем простая таблица «адрес → видимые units». Контракт отделяет экономическую долю пользователя от отображаемого количества.

В одной реализации это могут быть shares, в другой внутренние gons, fragments или иной fixed-point accounting. Пользователь взаимодействует с привычным balanceOf, но внутри контракт сначала берёт его долю, затем умножает или делит на глобальный коэффициент. Rebase меняет коэффициент, а не каждую запись в storage.

Share accounting помогает понять недилютивность

Представим, что у сети существует 1 млрд внутренних shares, которые никогда не меняются при rebase. Пользователь владеет 10 млн shares, то есть 1%. Видимый total supply может быть 100 млн units или 150 млн units, но его internal ownership остаётся 1%. balanceOf вычисляет 1% текущего supply.

Такой подход делает proportional adjustment математически естественным. Но он требует аккуратного округления: видимые units имеют конечную точность, а глобальный коэффициент может изменяться много раз. Контракт должен предотвращать накопление ошибок, которые в большой системе превращаются в материальную сумму.

Scaling factor — сердце elastic balance

Упрощённо можно представить balance = shares × scalingFactor. При positive rebase scalingFactor увеличивается, при negative уменьшается. Total supply рассчитывается похожим образом. Реальный код может использовать обратный коэффициент или другую математику, но концепция остаётся: одна глобальная величина масштабирует balances.

Проверяя контракт, найдите переменную, связанную с scaling, и функции, которые её изменяют. Посмотрите ограничения min/max, точность fixed-point arithmetic и обработку граничных значений. Это позволяет понять, может ли supply уйти в технически опасную область.

Allowance и approve требуют отдельной проверки

ERC-20 allowance обычно задаётся в units. Если balance пользователя меняется после rebase, allowance может остаться прежним числом и стать другой долей от его нового баланса. Например, разрешение на 100 units до negative rebase способно стать более значительным относительно оставшегося количества.

Некоторые реализации по-своему обрабатывают allowances. Поэтому при использовании DeFi не оставляйте бесконечные approve только потому, что balance динамический. Регулярно проверяйте разрешения и отзывайте ненужные.

Transfer между rebases обычно работает как у ERC-20, но accounting особенный

Пользователь отправляет видимые units, а контракт переводит соответствующее количество внутренних shares. После следующего rebase оба адреса получают proportional adjustment на оставшиеся доли. Это сохраняет привычную семантику transfer для пользователя, хотя storage устроен иначе.

При чтении raw events нужно помнить: событие Transfer фиксирует units на момент операции. Сравнивать исторические transfers с сегодняшним balance без учёта rebases некорректно.

Rebase event нужен для индексаторов

Контракт обычно публикует специальное событие с epoch и новым total supply или коэффициентом. Индексатор использует его, чтобы обновить портфели и графики. Если event отсутствует или нестандартен, сторонним приложениям сложнее поддерживать токен.

Для due diligence посмотрите, какие данные emit-ит policy. Хорошее событие позволяет независимо восстановить history: epoch, timestamp, old/new supply, rate или хотя бы параметры, из которых они вычисляются.

Rounding error должен быть экономически ограничен

Даже при идеальной формуле деление целых чисел создаёт округление. Один адрес может потерять доли минимальной единицы, а сумма dust по миллионам адресов — отличаться от теоретического supply. Контракт обязан иметь понятную стратегию округления.

Проверьте audits и tests вокруг min balances, очень крупного supply, repeated rebases и wrap/unwrap. Математический баг чаще проявляется именно на границах, а не в среднем сценарии.

Excluded addresses нарушают простую модель

Некоторые rebase-токены могут исключать определённые адреса из supply adjustment — например, системные контракты. Тогда пропорциональность для всей сети становится сложнее: часть balances fixed, часть elastic. Это не обязательно плохо, но должно быть явно описано.

Если исключений много, ownership share обычного держателя может меняться относительно excluded supply. Аналитик должен считать circulating/effective supply по реальным правилам, а не использовать простую формулу.

Wrapper преобразует shares в привычный fixed balance

Wrapper обычно принимает базовый rebase token, фиксирует долю underlying и выпускает fixed units. После rebase underlying balance wrapper contract меняется, поэтому стоимость одного wrapped unit в underlying меняется. Пользователь не видит ежедневного изменения количества, но экономический эффект не исчезает.

Такой дизайн удобен для accounting, lending и bridge. Однако conversion formula должна быть точной и защищённой от rounding/arbitrage bug. Проверьте preview wrap/unwrap на небольшом количестве и убедитесь, что on-chain redemption соответствует документации.

Migration меняет правила истории

Проект может обновить rebase policy, выпустить новую версию токена или wrapper. Тогда исторические данные старого контракта нельзя бесшовно соединять с новым без mapping. При анализе доходности отметьте дату migration и conversion ratio.

Если пользователь пропустил migration, выясните, можно ли обменять старый токен позже и кто контролирует migration contract. Не отправляйте средства на адрес из случайного сообщения якобы для перехода на новую версию.

Практические сценарии и итоговая методика работы с rebase-криптовалютой

Сценарий 1: баланс вырос на 25%, а пользователь считает это доходностью

Пользователь держал 4 000 units и после positive rebase увидел 5 000. Если смотреть только wallet, кажется, что он «получил» 1 000 токенов. Но total supply вырос тем же коэффициентом, поэтому ownership share не изменилась. Дальше нужно сравнить price и position value. Если price до rebase была 1,25, а после стала 1,00, стоимость осталась 5 000 в обоих случаях.

Вывод: positive rebase — изменение denomination. Прибыль появляется только если совокупная рыночная оценка позиции выросла. Для отчётности полезно записать units и value отдельно.

Сценарий 2: negative rebase вызывает панику

Баланс упал с 10 000 до 8 000 units. Пользователь решает, что протокол забрал 20%. Но total supply также уменьшился на 20%, ownership share сохранилась. Если price выросла с 0,80 до 1,05, стоимость изменилась с 8 000 до 8 400. В units произошёл contraction, в денежном выражении — рост.

Это не означает, что negative rebase полезен. Price могла не вырасти и value могла сильно упасть. Сценарий лишь показывает, что направление изменения units не равно направлению экономического результата.

Сценарий 3: wallet показывает разные balances

После rebase мобильный кошелёк показывает 1 200 units, explorer — 1 350, а dashboard — 1 347. Сначала сравните block number. Затем вызовите balanceOf на последнем подтверждённом блоке. Разница может быть обычной задержкой индексатора или округлением.

Не предпринимайте опасных действий, пока не проверите on-chain state. Никто из legitimate support не требует seed для «активации rebase».

Сценарий 4: пользователь внес rebase-token в AMM

Он ожидает, что positive rebase начислится прямо на wallet, но токены находятся на pool contract. Его wallet держит LP token. Rebase влияет на reserve, а economic benefit отражается через LP-share. Нужно считать value LP после adjustment и сравнивать с контрольным hold.

Если AMM не предназначен для elastic balance, reserves могут учесть rebase неправильно. Поэтому official compatibility важнее теоретической возможности сделать approve.

Сценарий 5: wrapper не меняет balance

У пользователя 100 wrapped units до и после positive rebase. Он думает, что пропустил начисление. На самом деле redemption rate изменился: каждая wrapped unit теперь соответствует большему количеству underlying. Если wrapper корректный, exposure сохраняется.

Для portfolio tracking нужно использовать price wrapper или current underlying per wrapper, а не ждать изменения token count.

Сценарий 6: длительное отклонение ниже target

Price остаётся ниже target 30 дней. Policy применяет серию negative rebases. Supply уменьшается, но спрос не восстанавливается. Liquidity тоже сокращается, потому что часть участников уходит. Это один из самых важных стресс-тестов: rebase policy не гарантирует mean reversion.

Инвестор должен оценить, что поддерживает demand помимо механики scarcity. Если ответ отсутствует, contraction способен продолжаться вместе с падением market value.

Сценарий 7: governance меняет curve

После голосования positive rebase становится мягче, negative — агрессивнее. Исторические backtests до обновления уже не полностью применимы. Пользователь должен разделить данные на policy regimes и сравнивать периоды отдельно.

Любая стратегия, основанная на rebase timing, обязана учитывать governance changes. Иначе модель оптимизируется на правилах, которых больше нет.

Сценарий 8: oracle incident

Oracle передаёт некорректное CPI или market rate, и protocol emergency process временно включает neutral rebase. Для пользователя это демонстрирует operational dependency. Если incident прозрачно описан, ошибка исправлена и safeguards усилены, это полезная информация для оценки зрелости.

Если команда скрывает причины или меняет данные задним числом без объяснения, governance risk выше.

Сценарий 9: lending-интеграция не поддерживает rebase

Интерфейс позволяет внести collateral, но docs не описывают elastic tokens. После negative rebase health factor неожиданно ухудшается сильнее или balance accounting расходится. Даже если проблема позже исправлена, пользователь уже мог попасть под liquidation.

Правило простое: сложный актив требует явной поддержки. Не экспериментируйте крупной суммой там, где integration не документирована.

Сценарий 10: пользователь сравнивает rebase с APR

График показывает, что за год balance вырос в два раза. Пользователь пишет «100% APY». Но если supply всей сети также удвоился, ownership не выросла. Реальная total return зависит от price. Сравнивать такой показатель с процентом по lending или staking некорректно.

Если нужен язык процентных ставок, сначала посчитайте денежный total return, а затем сравнивайте с альтернативой с тем же риском и горизонтом. Статья OneMagic про APR и APY помогает отделить ставку от изменения цены.

Сценарий 11: пользователь хочет купить только перед positive rebase

Он видит, что market rate выше target, и ожидает увеличение units. Но это публичная информация. Другие участники тоже знают о будущем adjustment, а price может измениться до и после epoch. Получение дополнительных units не создаёт преимущество, если supply увеличивается у всех.

Стратегия «купить перед positive rebase, продать после» требует backtest с market impact, gas, fees и реальным price path. Без статистики это не арбитраж, а speculation.

Сценарий 12: rebase-token используется в расчётах

Компания договаривается заплатить 10 000 units через месяц. За это время проходят rebases. Возникает вопрос: обязательство фиксировано в units или в purchasing power/target? Если договор этого не определяет, стороны могут понимать сумму по-разному.

Для коммерческих расчётов лучше заранее фиксировать economic unit и источник value. Elastic supply требует более точной формулировки, чем обычный токен.

Как сравнить rebase-token с fixed-supply активом

Составьте одинаковую таблицу: use case, demand source, supply policy, governance, liquidity, concentration, smart-contract risk, integration maturity и total return history. Rebase не должен получать бонус или штраф только за необычную механику. Важно, какую экономическую задачу он решает.

Если две альтернативы дают похожую exposure, но одна требует oracle, daily policy, wrapper и special integrations, сложность должна быть оправдана преимуществом.

Когда rebase-механика выглядит содержательной

Сильная модель имеет публичный target, прозрачный oracle, воспроизводимую policy, ограниченные admin powers, долгую историю работы, mature wrapper и понятный use case, где supply elasticity действительно нужна. Пользователь может независимо проверить rebases и ownership share.

Кроме того, спрос на токен не должен зависеть только от ожидания positive rebases. У актива есть функция, которая сохраняет смысл и в neutral/negative режимах.

Когда лучше отказаться

Если rebase formula скрыта, oracle централизован без safeguards, governance контролирует один ключ, liquidity слабая, wrapper нельзя нормально redeem, а вся реклама сводится к «баланс будет расти», риск чрезмерен. Механика слишком сложна, чтобы доверять обещаниям.

Отказ особенно разумен, если вы не можете объяснить, что произойдёт с balance и value при price на 30% ниже target в течение месяца.

Финальный чек-лист

• Я понимаю, зачем токену нужен elastic supply.
• Я знаю target и не считаю его гарантией выкупа.
• Я проверил oracle, heartbeat и stale-data protection.
• Я могу рассчитать rebase при нескольких price deviations.
• Я проверил ownership share до и после исторических rebases.
• Я знаю admin и governance права.
• Я понимаю wrapper и могу проверить redemption.
• Я проверил liquidity базового token и wrapper.
• Я использую только integrations с явной поддержкой rebase.
• Я умею считать position value, а не только units.
• Я подготовил stress test длительного contraction.
• Я веду историю для учёта и налогов.

Итог

Rebase-криптовалюта отличается от обычного токена тем, что протокол меняет не только рыночную цену через взаимодействие покупателей и продавцов, но и количество единиц через заранее заданную supply policy. Positive rebase расширяет предложение, negative сокращает, neutral оставляет его прежним. В недилютивной модели balance и total supply меняются пропорционально, поэтому доля держателя сохраняется.

Главная ошибка — смотреть на количество токенов отдельно от стоимости. Дополнительные units не равны прибыли, а сокращение units не равно автоматическому убытку. Оценивайте balance × price, ownership share, liquidity, market cap и историю policy. Если rebase используется внутри DeFi, дополнительно проверяйте совместимость AMM, lending, bridge, vault и wrapper.

Наиболее профессиональный подход — анализировать rebase как цепочку: target → oracle → policy → scalar → supply → market → integrations. Если хотя бы один слой непрозрачен, риск возрастает. Если все слои проверяемы, rebase перестаёт выглядеть магией и превращается в понятную, хотя и сложную, денежную механику.

Перед вложением средств вернитесь к общей проверке токена, ликвидности и предложения. Rebase — лишь один параметр, и он не должен перекрывать качество продукта, права управления и реальную возможность выйти из позиции.

Дополнительный расчёт: как меняется доля и стоимость при серии rebases

Один rebase понять легко, но серия быстро запутывает. Представим, что у пользователя 10 000 units из total supply 1 000 000, то есть 1%. Первый день — positive rebase +10%: balance становится 11 000, supply 1 100 000. Второй день — negative rebase −20%: balance 8 800, supply 880 000. Третий день — positive +5%: balance 9 240, supply 924 000. После трёх adjustments у пользователя меньше units, чем в начале, но его ownership share по-прежнему 1%.

Теперь добавим price. Если в начале unit стоила $1,00, position value была $10 000. После первой корректировки price может стать $0,95, и value — $10 450. После второй price может подняться до $1,15, и value — $10 120. После третьей price $1,08 — value около $9 979. Несмотря на драматические изменения units, итог почти нулевой. Этот пример показывает, почему нельзя складывать проценты rebases как инвестиционную доходность.

Для нескольких периодов коэффициенты перемножаются, а не складываются. +10%, затем −20% дают factor 1,10 × 0,80 = 0,88, то есть units на 12% ниже старта. Аналогично +50% и −50% не возвращают balance к исходному: 1,5 × 0,5 = 0,75. Это обычная математика последовательных процентных изменений, но в rebase она особенно важна из-за частых adjustments.

Дополнительный расчёт: wrapper как доля сети

Допустим, wrapper имеет фиксированный supply 10 млн units, а один wrapped token представляет определённую долю всей rebase-сети. Пользователь держит 100 wrapped units. Пока underlying supply расширяется, количество wrapped units не меняется, но unwrap выдаёт больше underlying units. При contraction — меньше. Экономически holder сохраняет долю, но volatility перемещается из token count в exchange rate и price wrapper.

Такое представление удобно для интеграций, потому что lending или portfolio system видит fixed balance. Однако пользователь должен понимать, что fixed balance не означает fixed value. Если underlying network market cap падает, wrapper price тоже может падать. Wrapper решает техническую совместимость, а не рыночный риск.

При проверке wrapper полезно рассчитать conversion на трёх исторических точках. Возьмите amount underlying, который выдавался за 1 wrapped unit до positive rebase, после него и после negative rebase. Если формула прозрачна, изменение будет соответствовать доле сети. Любое unexplained deviation требует проверки contract state, fee или rounding.

Дополнительный аудит: как вести журнал rebase-позиции

Создайте таблицу с колонками Date, Block, Market Rate, Target, Rebase %, Balance, Total Supply, Ownership %, Price, Position Value, Wrapped Rate, Notes. Не обязательно заполнять её вручную каждый день: данные можно автоматизировать, но структура помогает понимать, что именно измеряется. Для крупной позиции такой журнал становится частью risk management.

Отдельно фиксируйте собственные transactions: buy, sell, transfer, wrap, unwrap, deposit в DeFi, withdrawal. Тогда можно разделить изменения balance на три категории: действия пользователя, protocol rebase и внешняя DeFi accounting. Без такого разделения любой отчёт через несколько месяцев становится недостоверным.

Полезно добавлять колонку Policy Version. Если governance меняет curve или oracle, новая версия получает отдельный номер. Тогда исторический analysis не смешивает разные monetary regimes. Это особенно важно для backtest: стратегия, работавшая при reaction lag 10, не обязана работать после перехода на другую sigmoid curve.

Как не перепутать rebase с отражением цены в интерфейсе

Некоторые приложения показывают portfolio value в фиате и token balance рядом. После rebase оба показателя могут обновляться с разной скоростью. Например, balance уже новый, а price feed ещё старая; на несколько минут приложение показывает огромную прибыль или убыток. Это артефакт синхронизации.

Проверяйте timestamp price и block height balance. Для корректного snapshot обе величины должны относиться примерно к одному времени. Аналогичная проблема возникает при историческом экспорте: если daily balance берётся после rebase, а close price — до него, расчёт total return будет искажён.

Поэтому профессиональная аналитика использует согласованные snapshots. Это техническая деталь, но она способна полностью перевернуть вывод о результативности rebase-стратегии.

Как оценить экономическую полезность elastic supply

Задайте вопрос: какую проблему решает изменение units, которую нельзя решить проще? У unit-of-account модели ответ может быть связан с попыткой переносить volatility спроса из unit price в supply. У других проектов rebase используется для target exposure, index-like поведения или специфической DeFi конструкции. Если ответ сводится к «так токен выглядит доходнее», это плохой признак.

Далее определите пользователя, которому механизм действительно полезен. Трейдеру fixed units обычно привычнее. Бухгалтерии — тоже. DeFi developer может предпочесть wrapper. Если native rebase форма имеет реальный use case, должно быть понятно, зачем кому-то держать её именно в elastic виде, а не только wrapper.

Наконец, сравните network effects и integration costs. Механика может быть теоретически элегантной, но если кошельки, lending и bridges постоянно ломаются на изменяющемся balance, практическая полезность снижается. Сильный проект решает эту проблему стандартами, wrappers, SDK и зрелой документацией.