Сейчас в контракте на исполнение обратного выкупа $PONS осталось около 136 тысяч долларов
Я подумал: может быть, в протоколах, которые действительно исполняют обратный выкуп, более гибкий механизм выкупа будет лучше, чем механический автоматический выкуп? @MEADGod
Например, при анализе исторического движения цены, если определяется, что сейчас нисходящий тренд, выкупать большую долю.
И наоборот: если определяется восходящий тренд, уменьшать эту долю.
Например, сейчас каждый час выкупается около 0.46e PONS — это базовое почасовое значение для текущего периода.
（1）Если по итогам анализа последних 20 часовых свечей определяется нисходящий тренд, объём выкупа составит 0.6e в час (1.3 от базового объёма).
（2）При восходящем тренде объём выкупа будет скорректирован до 0.32e в час (0.7 от базового объёма).
（3）При нейтральном рынке объём выкупа будет в основном соответствовать базовому значению.
Я попросил ИИ сделать простую диаграмму, чтобы всем было понятнее.
Суть здесь не в том, чтобы протокол выделял сверх запланированного, а в том, чтобы по-разному распределять один и тот же бюджет при разных ценах.
Средства, которые не тратятся на выкуп во время роста, будут поступать в отдельный пул для обратного выкупа. Во время снижения цены из этого пула можно будет направлять больше средств на выкуп. Так мы сохраним постоянный выкуп и при этом сможем покупать больше PONS и сжигать больше токенов за те же деньги, когда цена ниже.
Анализ только последних 20 часовых свечей — просто пример, но сам механизм несложно реализовать. Я могу сделать это с помощью Codex (я уже реализовывал похожее распознавание, когда создавал бота для мониторинга рынка).
Более разумно перед исполнением каждого периода анализировать движение цены $PONS за последнюю неделю.
У этой схемы есть и проблема: если на протяжении некоторого времени сохраняется нисходящий тренд, средства в таких рыночных условиях будут расходоваться быстрее.
Поэтому лучше запускать такой гибкий механизм во время восходящего тренда, заранее резервируя исходные 30% средств в пуле.
Впрочем, реализовать это и на текущем этапе тоже можно. Для контракта можно задать ограничение: перед исполнением периода проверять остаток в резервном пуле. Если он меньше 0.3 от общего объёма средств на период, в текущем периоде выкуп по умолчанию будет идти по базовому значению.
➠ То есть, допустим, в этом периоде на выкуп доступно 10E. Если в резервном пуле, оставшемся после предыдущего периода, меньше 3E, то в текущем периоде на выкуп по умолчанию будет направлено 10E, а не 13E
Я подумал: может быть, в протоколах, которые действительно исполняют обратный выкуп, более гибкий механизм выкупа будет лучше, чем механический автоматический выкуп? @MEADGod
Например, при анализе исторического движения цены, если определяется, что сейчас нисходящий тренд, выкупать большую долю.
И наоборот: если определяется восходящий тренд, уменьшать эту долю.
Например, сейчас каждый час выкупается около 0.46e PONS — это базовое почасовое значение для текущего периода.
（1）Если по итогам анализа последних 20 часовых свечей определяется нисходящий тренд, объём выкупа составит 0.6e в час (1.3 от базового объёма).
（2）При восходящем тренде объём выкупа будет скорректирован до 0.32e в час (0.7 от базового объёма).
（3）При нейтральном рынке объём выкупа будет в основном соответствовать базовому значению.
Я попросил ИИ сделать простую диаграмму, чтобы всем было понятнее.
Суть здесь не в том, чтобы протокол выделял сверх запланированного, а в том, чтобы по-разному распределять один и тот же бюджет при разных ценах.
Средства, которые не тратятся на выкуп во время роста, будут поступать в отдельный пул для обратного выкупа. Во время снижения цены из этого пула можно будет направлять больше средств на выкуп. Так мы сохраним постоянный выкуп и при этом сможем покупать больше PONS и сжигать больше токенов за те же деньги, когда цена ниже.
Анализ только последних 20 часовых свечей — просто пример, но сам механизм несложно реализовать. Я могу сделать это с помощью Codex (я уже реализовывал похожее распознавание, когда создавал бота для мониторинга рынка).
Более разумно перед исполнением каждого периода анализировать движение цены $PONS за последнюю неделю.
У этой схемы есть и проблема: если на протяжении некоторого времени сохраняется нисходящий тренд, средства в таких рыночных условиях будут расходоваться быстрее.
Поэтому лучше запускать такой гибкий механизм во время восходящего тренда, заранее резервируя исходные 30% средств в пуле.
Впрочем, реализовать это и на текущем этапе тоже можно. Для контракта можно задать ограничение: перед исполнением периода проверять остаток в резервном пуле. Если он меньше 0.3 от общего объёма средств на период, в текущем периоде выкуп по умолчанию будет идти по базовому значению.
➠ То есть, допустим, в этом периоде на выкуп доступно 10E. Если в резервном пуле, оставшемся после предыдущего периода, меньше 3E, то в текущем периоде на выкуп по умолчанию будет направлено 10E, а не 13E