GongFu 功夫

Версия 1.0 - Mainnet edition

Бери достаточно. Укрепляй систему, которая поддерживает всех.

#О документе

Этот whitepaper описывает правила первой mainnet-версии GongFu: устройство резерва, права участников, ограничения, источники цены, логику наград, WindDown и основные риски.

Документ объясняет систему, но не заменяет проверку развёрнутого контракта. Перед взаимодействием пользователь сверяет официальный адрес GF, адрес GongFu, исходный код, байткод и неизменяемые параметры через публичный deployment manifest и block explorer Robinhood Chain.

GongFu не является банковским вкладом, инвестиционным договором или обещанием доходности. Цена GF, ликвидность рынка, размер фактической награды и срок жизни reward-фазы заранее неизвестны.

Приоритет протокола:

Security > Sustainability > Simplicity > Features.

#1. Суть GongFu за две минуты

GongFu - неизменяемый Solidity-смарт-контракт на Robinhood Chain. Он хранит общий резерв GF и принимает временные размещения участников по одинаковым для всех правилам.

Пользователь не передаёт GF команде или управляющей компании. Он отправляет их непосредственно в смарт-контракт. У контракта нет приватного ключа, владельца, администратора или скрытой функции вывода. GF могут покинуть резерв только по публичным правилам, записанным в развёрнутом байткоде.

Участник выбирает срок, переводит GF в контракт и ждёт его окончания. На 90 и 180 дней награда приходит частями раз в месяц, а основная сумма возвращается в конце срока. Она остаётся точным обязательством протокола перед владельцем позиции. Награда не создаётся из воздуха и не минтится: она может быть выделена только из свободной части уже существующего резерва.

Главная защита GongFu - WindDown. Если свободного резерва недостаточно для продолжения reward-фазы, контракт необратимо прекращает новые размещения и новые награды. При этом основная сумма каждого участника остаётся доступной владельцу через ручной claim. GongFu не превращает principal одного участника в награду другому и не создаёт ситуацию, в которой последний пользователь теряет свои GF только потому, что пришёл позже остальных.

WindDown - не аварийная кнопка разработчика. Это заранее записанный честный режим завершения reward-фазы, который никто не может отменить или изменить.

#2. Зачем существует протокол

Многие reward-протоколы зависят от одного или нескольких источников:

• постоянной эмиссии новых токенов;
• бесконечного притока новых участников;
• внешней доходности, которая может исчезнуть;
• ручного управления резервом.

GongFu строится от обратного. Резерв конечен. Поэтому контракт не обещает бесконечную награду, не скрывает обязательства и заранее определяет, что произойдёт при нехватке свободных средств.

Экономический вопрос GongFu звучит так:

Может ли общий резерв долго работать, если основная сумма защищена, большие личные лимиты нужно заслужить временем, а правила нельзя менять в пользу создателя?

GongFu не доказывает ответ маркетингом. Протокол публикует правила, код, deployment manifest и исследовательскую лабораторию. Хороший результат модели не является гарантией будущего результата.

#3. Базовые понятия

В интерфейсе используются простые названия. Технические термины сохранены в скобках, чтобы действия в кабинете можно было сопоставить с функциями контракта.

#4. Сеть, токен и запуск

#4.1 Robinhood Chain

GongFu работает на Robinhood Chain - EVM-совместимой Ethereum L2-сети на базе Arbitrum. Mainnet chain ID равен 4663, нативный gas-актив - ETH.

Фактический плательщик транзакции оплачивает весь network gas. GongFu не возмещает ETH и не удерживает комиссию из principal, reward, contribution, referral-баланса или резерва. Добровольный сторонний gas sponsor возможен, но не является обязанностью протокола.

#4.2 Токен GF

GF создаётся на launchpad Pons (V2) в сети Robinhood Chain как один канонический ERC-20 с фиксированным предложением:

1 000 000 000 GF

Канонический GF не имеет:

• дополнительного mint после выпуска;
• pause, freeze или blacklist;
• fee-on-transfer;
• rebase;
• hooks или callbacks;
• upgrade;
• второй канонической версии токена.

Технически GF — стандартный токен Pons: небольшой неизменяемый ERC-20 без владельца. Всё предложение выпускается один раз при создании и сразу поступает на кривую запуска Pons (раздел 4.5). У токена есть только переводы, разрешения (approve) и сжигание держателем собственных GF (burn); функций mint, pause, смены кода или изменения чужих балансов нет. Сжигание может только уменьшить предложение, но не увеличить его.

GongFu принимает только закреплённый в контракте GF. Адрес токена, decimals, total supply и runtime code проверяются до активации протокола.

#4.3 Постоянный первоначальный резерв

До активации в GongFu передаётся не менее:

500 000 000 GF

Это половина всего предложения. Pons не выделяет создателю отдельной доли: все токены продаются с кривой. Поэтому резерв покупается. Служебный адрес запуска покупает 500 000 000 GF в той же транзакции, которой создаётся токен (launchAndBuy), — раньше, чем кто-либо ещё может купить. При параметрах Pons на момент написания это стоит около 3 269 USDG, включая комиссию кривой 1%.

Сразу после этого служебный адрес развёртывает контракт GongFu и переводит в него все 500 000 000 GF (fundPermanentSupport); остаток покупки сверх 500 000 000 GF тоже уходит в резерв. Между покупкой и переводом проходит несколько минут. Это единственный момент, когда резерв зависит от приватного ключа: если ключ будет скомпрометирован именно тогда, резерв может не поступить в контракт. Все транзакции запуска публикуются в deployment manifest, и любой может проверить, что купленные GF целиком переведены в GongFu. Контракт не активируется без полного резерва (раздел 4.4).

Предложение 1 000 000 000 GF после запуска распределяется так:

Последние две части Pons резервирует сам и не продаёт с кривой; команда не получает из них ничего.

Эти GF составляют первоначальную подушку общего резерва. После передачи они:

• не являются treasury разработчика;
• не дают создателю право на возврат;
• не могут быть выведены отдельной owner/admin-функцией;
• могут покинуть контракт только по неизменяемым правилам claims и settlement.

Происхождение токенов раскрывается публично, но не создаёт для создателя особого права внутри GongFu.

#4.4 Активация

Mainnet-публикация и активация происходят только после общей проверки:

• одного канонического GF;
• фактического резерва не менее 500 миллионов GF;
• канонического рынка и quote asset;
• достаточной ликвидности и приемлемой стоимости манипуляции;
• одного исправного закреплённого Uniswap V4 GF/USDG spot-маршрута;
• неизменяемых constructor-параметров и deployment manifest.

На уровне on-chain state переход в Active permissionless: его может вызвать любой адрес, но только если контракт уже видит точный первоначальный резерв и единственный допустимый маршрут. Канонический рынок, его ликвидность и стоимость манипуляции раскрываются и проверяются отдельно в mainnet deployment manifest. У GongFu нет привилегированной функции активации с ослабленными условиями.

Активация возможна только после выхода GF с кривой Pons на пул Uniswap V4 (раздел 4.5). Пока кривая не выкуплена, пула ещё нет, маршрут цены не видит рынка, и Active недостижим. После выхода на пул контракт может активировать любой; первое поколение активируется вручную, без бота.

Активация также задаёт начальную эталонную цену (раздел 14). Она равна минимальной допустимой цене маршрута — порогу активации, — а не spot-цене в момент активации. Поэтому разогнать цену, чтобы активировать раньше, и сразу получить выгоду от разогнанной цены нельзя.

#4.5 Рынок на запуске

Рынок GF проходит две фазы.

Кривая Pons. После создания токен торгуется на кривой Pons в паре GF/USDG. Это кривая постоянного произведения с виртуальным («фантомным») резервом 3 236 USDG; реальных USDG на старте в ней нет, цена растёт только от покупок. Параметры кривой на момент написания:

• первая покупка служебного адреса (500 000 000 GF) поднимает цену примерно с 3,2 до 12,9 µUSD за GF — с этой цены начинается свободный рынок;
• кривая закрывается, когда в неё поступило 8 090 USDG; остальные ≈214 млн GF рынок покупает примерно за 4 900 USDG, и цена на закрытии ≈39,6 µUSD (FDV ≈ $39 600);
• каждая сделка на кривой платит комиссию 1%;
• в первые секунды после создания Pons применяет повышенный налог против снайперов; покупка служебного адреса в транзакции создания под него не попадает;
• лимита баланса на адрес нет.

Пока кривая не закрыта, маршрут цены GongFu не видит рынка, и активация невозможна (раздел 4.4).

Пул Uniswap V4. Когда кривая выкуплена, любой может вызвать перевод на пул (createGraduatedPool). Pons создаёт пул Uniswap V4 GF/USDG (комиссия пула 0, tickSpacing 200, хук Pons) по цене закрытия кривой и кладёт в него собранные 8 090 USDG и ≈204 млн GF. Это тот пул, из которого GongFu берёт цену (раздел 14):

• ликвидность пула заблокирована навсегда и не может быть выведена ни командой, ни Pons;
• миграции дальше нет: пул остаётся основным рынком GF;
• инициализировать пул раньше закрытия кривой посторонний не может — хук Pons отклоняет такую попытку.

Точные параметры кривой и пула сверяются набором запуска перед отправкой первой транзакции и публикуются в deployment manifest; если Pons изменит их до запуска, запуск остановится, ничего не отправив.

#5. Что хранит смарт-контракт

#5.1 Состояние протокола

Контракт хранит:

• режим Bootstrap, Active или WindDown;
• общий долг по principal;
• общий долг по подтверждённым наградам;
• общий долг по личным referral-балансам;
• число открытых позиций;
• очередь окон расчёта наград;
• время необратимого перехода в WindDown.

#5.2 Состояние участника

Для каждого адреса хранится только необходимая информация:

• зарегистрирован ли участник;
• максимальный открытый срок;
• история успешных Continue;
• активный USD-notional по каждому сроку и в целом;
• накопленный referral-баланс;
• накопленный donation-notional;
• число позиций, где principal уже получен, но выбор Exit/Continue ещё не завершён;
• закрыт ли адрес для новых размещений после Exit.

Запись участника постоянна. Она не закрывается и не конфискуется, потому что на неё позднее могут поступить referral-права.

#5.3 Позиция

Каждая позиция имеет уникальную последовательность внутри адреса и хранит:

• владельца;
• principal в минимальных единицах GF;
• выбранный срок;
• время открытия и точный maturity;
• принятый GF/USD snapshot;
• USD-notional на входе;
• максимальную награду;
• сохранённых рефереров;
• состояние principal, owner reward и referral-компонентов;
• признак ожидающего выбора владельца;
• признак окончательной финализации.

Существующая позиция не переоценивается из-за последующего изменения рынка.

#6. Бухгалтерия резерва

Баланс контракта нельзя целиком считать свободным резервом. GongFu разделяет его на защищённые обязательства и доступный surplus.

protected liabilities = principal liability
                      + settled epoch liability
                      + personal referral liability

available surplus = contract GF balance - protected liabilities

Главный инвариант:

contract GF balance >= protected liabilities

Principal никогда не считается свободным резервом. Нерассчитанная максимальная награда учитывается как будущий риск, но не становится защищённым долгом до settlement соответствующего окна.

Все production-расчёты выполняются checked integer arithmetic. Floating point в контракте не используется. Направление округления выбирается заранее и не может меняться от пользователя к пользователю.

Потерянный ключ не передаёт GF сообществу. Невостребованная сумма остаётся защищённым обязательством без срока сгорания.

#7. Сроки, доступ и максимальная награда

GongFu поддерживает ровно пять сроков:

Это максимумы, а не обещание доходности. Фактическая награда может быть меньше и определяется только после settlement из реально доступного surplus.

На 90 и 180 дней максимальная награда приходит равными частями раз в месяц: 3 части по 1/3 для 90 дней и 6 частей по 1/6 для 180 дней (раздел 9.3). Ставки и лимиты от этого не меняются, principal по-прежнему заблокирован до конца срока.

Новый адрес начинает с history-уровня SevenDays и 20% earned-history capacity. Позиция на 1 день остаётся optional с собственным 10% duration limit и максимальной наградой 0,16%, но успешный Continue 1-дневной позиции не продвигает history. Успешный Continue текущего 7-дневного максимума открывает следующий шаг:

7D -> Continue -> 30D -> Continue -> 90D -> Continue -> 180D

Само окончание срока не открывает следующий уровень. Один успешный Continue 180-дневной позиции открывает 100% лимита, заработанного историей участия.

Лимит, заработанный историей, сверх стартовых 20% ограничен ещё и размером самой истории. Он не может превышать четырёхкратную стоимость (по текущей цене) principal той позиции, завершение которой открыло текущий уровень. Пока участник уже на полном уровне, учитывается крупнейшая такая позиция. Мера считается в GF, поэтому рост цены не мешает продлить то же количество GF. История из крошечных позиций открывает более длинные сроки, но не больший лимит: такой адрес остаётся на стартовых 20%, как новый.

Количество позиций отдельно не ограничено. Ограничивается их общая активная USD-стоимость, поэтому дробление одной суммы на множество транзакций не создаёт дополнительный лимит.

#8. Личный лимит MaxCap

MaxCap ограничивает активную долларовую стоимость позиций одного адреса. Это anti-whale и sustainability-механизм, а не рекомендуемый размер размещения.

Рыночная база вычисляется из принятой GF/USD цены и фиксированного предложения:

GF FDV = GF/USD price * 1 000 000 000 GF
m = GF FDV / 1 000 000 USD

TotalCapUSD = max(
  500,
  100 000 * m^0.746 / (m^0.746 + 39)
)

Базовый Total MaxCap начинается с $500 и плавно приближается к $100 000. Рост сублинейный: увеличение FDV не создаёт бесконечный личный лимит.

Для нового Open или Continue сначала должен быть доступен единственный ценовой маршрут; затем контракт берёт минимум из применимых потолков:

available capacity = min(
  remaining Total MaxCap,
  remaining duration ceiling,
  remaining earned-history ceiling
)

Donation boost может дополнительно повысить потолок только для 30, 90 и 180 дней. Он не отменяет ограничения срока, истории и уже занятого лимита.

Позиция занимает MaxCap, пока её principal не получен владельцем. Maturity, settlement и простой ход времени не освобождают лимит. Записанный notional удаляется ровно один раз только в той же успешной транзакции, которая возвращает principal. Неуспешный claim или Continue не освобождает ничего.

Для MaxCap позиция оценивается по большей из двух цен — spot и эталонной (раздел 14). По ней же считается и Total MaxCap. Опустить цену внутри своей транзакции, чтобы уместить больше GF, поэтому нельзя.

Существующие позиции не пересчитываются по новой цене. Если текущий маршрут недоступен, новые price-dependent действия не получают capacity; существующие позиции не меняются.

V1 не вводит отдельный глобальный предел общей незаклеймленной principal-суммы и отдельный предел концентрации в одном шестичасовом окне. Точное покрытие principal и личный MaxCap остаются обязательными.

#9. Жизненный цикл позиции

#9.1 Регистрация

Участник регистрирует адрес один раз. Если очередь подходящих рефереров пуста, регистрация проходит без реферера, а referral-компоненты этой связи равны нулю.

Когда подходящие участники появляются, автоматическое назначение использует детерминированный bounded O(1) round-robin. Caller не выбирает более выгодного реферера. В очередь входит только участник, у которого есть хотя бы один лично приглашённый пользователь с активной позицией стоимостью не менее $50. Стоимость считается по цене фиксации этой позиции. Позиции меньше $50 работают как обычно, но не ставят пригласившего в очередь, поэтому занять очередь тысячами пустых кошельков дорого. Автоматически назначенная связь не считается личным приглашением.

#9.2 Создание позиции

Участник выбирает сумму и один доступный срок. Контракт в одной транзакции:

1. проверяет режим Active;
2. проверяет регистрацию, доступный срок и отсутствие незавершённого выбора;
3. получает каноническую spot-цену GF/USD и эталонную цену;
4. рассчитывает MaxCap и exact USD-notional по большей из них, а цену фиксации позиции записывает по меньшей;
5. принимает точное количество GF;
6. создаёт позицию и привязывает её к maturity-окну;
7. увеличивает principal liability и активный notional на одинаково проверяемые значения.

Пользователь не передаёт контракту цену, ценовой маршрут, reward rate, referrer или готовый MaxCap. Эти значения выводятся из неизменяемого состояния.

#9.3 Активный срок

До maturity ранний вывод отключён. Исключение возникает только после необратимого WindDown, когда principal становится доступным независимо от оставшегося срока.

Reward не начисляется ежедневным переводом, не compound автоматически и не растёт после maturity.

Ежемесячные части для 90 и 180 дней. Максимальная награда позиции на 90 дней делится на 3 равные части, на 180 дней — на 6. Каждая часть, кроме последней, привязана к maturity-окну своего месяца: окну, в которое попадает момент «открытие + 30 дней», «+ 60 дней» и так далее. Последняя часть рассчитывается в окне окончания самой позиции.

• Часть рассчитывается вместе со всеми позициями своего окна и получает тот же пропорциональный payout scale (раздел 9.4). Отдельного резерва под неё нет.
• После расчёта владелец забирает часть в любое время (claimMonthlyReward). Если окно уже созрело, но ещё не рассчитано, та же транзакция сначала его рассчитывает.
• Referral-доли 7/3/2% начисляются с каждой части отдельно, когда она выплачивается. Любой может заранее перенести их реферерам (rollupMonthlyReferrals), не дожидаясь владельца.
• Principal остаётся заблокированным до конца срока. Principal-first claim, Exit и Continue работают как раньше и касаются principal и последней части.
• Остаток от деления (доли наименьшей единицы GF) добавляется к последней части, поэтому сумма частей ровно равна максимальной награде.

Позиции на 1, 7 и 30 дней не меняются: вся их награда рассчитывается в окне окончания.

#9.4 Расчёт награды

Позиции объединяются в глобальные шестичасовые maturity-окна только для расчёта reward. Точный момент maturity каждой позиции не меняется и не откладывается до конца окна.

Окна рассчитываются строго от самого старого к новому, по одному окну за шаг, поэтому контракт никогда не обходит неограниченный список пользователей. Отдельный оператор для этого не нужен: каждый новый вклад, каждое продление и каждый выход с наградой сначала сами рассчитывают созревшие окна (до 32 за транзакцию; выход — только до своего окна), а затем выполняют своё действие. После WindDown вывод участника сам отменяет окна, стоящие в очереди перед его окном. Если системой долго никто не пользовался, любой может рассчитать накопившиеся окна одним вызовом (settleMatureHeads), а после WindDown — так же отменить их (cancelWindDownHeads). Если такой расчёт сам запускает WindDown или созревших окон больше, чем рассчитывается за одну транзакцию, сделанный расчёт сохраняется, а действие завершается без выполнения и без списания средств: вклад или продление достаточно повторить. Выход после WindDown сразу выплачивает средства по правилам WindDown. Если перед окном участника стоит больше 256 окон, вывод после WindDown сохраняет сделанную отмену и тоже просит повторить. Если цена недоступна, а вклад уже рассчитал созревшие окна, расчёт сохраняется, а вклад завершается без выполнения.

Максимальная награда позиции не резервируется в момент её открытия. Награда определяется только при расчёте её окна из surplus, свободного в этот момент. Окна рассчитываются в порядке созревания, а не в порядке открытия позиций. Поэтому длинная позиция может ждать своего окна за более поздними короткими, которые созревают раньше и получают награду из того же резерва первыми.

Ежемесячная часть позиции на 90 или 180 дней — отдельная запись в окне своего месяца. Для расчёта окна она ничем не отличается от позиции, которая в нём созревает.

Все позиции одного окна получают общий пропорциональный payout scale. Если их суммарная максимальная награда равна 100 000 GF, а доступно только 60 000 GF, каждая получает 60% своего максимума. Порядок claims пользователей не создаёт преимущества первому.

#9.5 Principal-first claim

Сразу после точного maturity владелец может получить principal, даже если reward-окно ещё не рассчитано. Такая транзакция:

• возвращает ровно principal;
• освобождает notional позиции ровно один раз;
• не выплачивает reward;
• не удерживает contribution;
• сохраняет будущие owner и referral-права;
• не выбирает Exit или Continue за пользователя.

До последующего выбора адрес не может открыть несвязанную новую позицию. После settlement владелец завершает именно эту позицию через Exit или Continue. Если раньше включился WindDown, применяется terminal claim без возможности продолжения.

#10. Два выбора после settlement

#10.1 Exit - забрать всё

Exit возвращает:

• весь ещё не полученный principal;
• всю фактически settled owner reward (для 90 и 180 дней — последней части; ежемесячные части забираются отдельно и Exit не нужны);
• без contribution.

Если principal уже был получен через principal-first claim, Exit выплачивает только settled reward и не освобождает MaxCap второй раз.

После Exit адрес навсегда закрывается для новых Open и Continue. Другие уже существующие позиции остаются claimable. Средства не конфискуются. Новый адрес начинает путь заново с 7-дневного history-уровня; optional 1-дневная позиция не продвигает history.

#10.2 Continue - продолжить участие

Continue завершает старую позицию и создаёт новую в одной атомарной транзакции. Контракт:

1. определяет ещё не выплаченный principal и settled owner reward (для 90 и 180 дней — последней части);
2. рассчитывает текущий MaxCap и доступный срок;
3. определяет реальную сумму новой позиции;
4. рассчитывает contribution из settled owner reward старой позиции (для 90 и 180 дней — только из последней части);
5. переносит referral-права в личные балансы рефереров;
6. создаёт новую позицию;
7. выплачивает владельцу остаток.

Если прежнее количество GF больше не помещается в текущий долларовый MaxCap, контракт размещает только допустимую часть, а остаток возвращает владельцу. Минимальной суммы Continue нет. Если новая позиция не создаётся, contribution равен нулю.

Если principal уже был получен ранее, GF для новой позиции должны реально поступить от владельца. Старый principal нельзя виртуально использовать второй раз.

Contribution зависит от gross value multiple. Контракт сравнивает стоимость principal по записанной цене фиксации со стоимостью principal + settled owner reward по большей из spot и эталонной цены на момент Continue. Опустить цену внутри своей транзакции, чтобы попасть в меньшую ставку, поэтому нельзя:

Contribution применяется только при Continue и только к заработанной награде: ставка берётся со всей settled owner reward старой позиции, даже если в новую позицию вносится меньше GF. Для 90 и 180 дней это награда последней части: уже полученные ежемесячные части contribution не затрагивает, и multiple тоже считается по последней части. Principal не удерживается ни при каком multiple.

#11. WindDown: основная сумма не остаётся запертой

WindDown - необратимое состояние, защищающее права владельцев, когда свободный резерв больше не может поддерживать новые награды.

При settlement старейшего maturity-окна контракт сначала сохраняет покрытие principal и уже подтверждённых прав. Если свободного резерва недостаточно для полного максимума нового окна, доступный surplus распределяется пропорционально, после чего GongFu входит в WindDown.

После WindDown:

new Open = disabled
Continue = disabled
new rewards = disabled
contribution = disabled
all principal = owner pull-claimable

Основная сумма каждой позиции становится доступной владельцу независимо от того, закончился её срок или нет. Уже settled rewards сохраняются как защищённые обязательства. Это касается и ежемесячных частей позиций на 90 и 180 дней: часть, окно которой рассчитано до WindDown (включая окно, которое его запустило), можно забрать в любое время, а части в нерассчитанных окнах отменяются вместе с этими окнами. Reward окна, которое не было settled, получает окончательный статус отсутствия награды, но principal его позиций сохраняется полностью.

Контракт не выполняет массовую рассылку. Каждый владелец вручную вызывает claim для своей позиции. Это не создаёт гонку, в которой первый забирает principal последнего: весь principal уже учитывается отдельно от surplus.

WindDown не может быть отменён donation, создателем, ценовым маршрутом, интерфейсом или любой последующей транзакцией. Он не меняет старые правила и не создаёт привилегированный вывод.

В рамках правил GongFu principal не используется для наград, contribution или donation и всегда сохраняет owner-authorized claim route. Как и любой on-chain механизм, исполнение транзакции всё равно зависит от доступности сети, сохранности ключа и отсутствия неизвестной ошибки в коде.

WindDown завершает reward-фазу этого поколения GongFu, но не эксперимент в целом. Что происходит дальше, описано в разделе 19 «Поколения».

#12. Referral-система

V1 использует не более трёх referral-уровней:

Общая referral-доля не превышает 12% и никогда не рассчитывается от principal.

При Exit или Continue все оставшиеся referral-компоненты позиции получают окончательное состояние. Положительные суммы переходят из долга maturity-окна в накопительные личные балансы сохранённых рефереров. GF при этом не покидают контракт, подпись реферера не нужна, а общая защищённая сумма не меняется.

Перенос referral-прав рассчитанной позиции может выполнить любой адрес, не дожидаясь владельца, и в Active, и после WindDown. Поэтому реферер не зависит от того, вернётся ли приглашённый за своей выплатой. Выплату владельца это не меняет.

Реферер позднее вручную получает весь накопленный баланс одной транзакцией. Баланс не имеет срока сгорания, не конфискуется, не превращается в donation и не зависит от дальнейшего участия реферера.

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

В следующем поколении связи приглашений сохраняются (раздел 19.8).

#13. Donations и выкуп из комиссий

#13.1 Donation

Donation - безвозвратная поддержка резерва. Она не создаёт principal, reward, referral, право голоса или право возврата GF.

Контракт принимает любую положительную сумму GF. Donation увеличивает surplus и не повышает reward rate.

Для 30, 90 и 180-дневных позиций donation history может дать ограниченный дополнительный MaxCap boost:

D = cumulative donated USD notional

donationBoostUSD = 15 000 * D / (D + 250 000)

При $250 000 cumulative donation-notional boost равен $7 500. При $1 000 000 он равен $12 000. Теоретический потолок boost - $15 000, поэтому максимальная агрегированная база равна $115 000 до применения остальных ограничений.

Capacity boost - вторичный бонус, а не смысл donation. Любая положительная сумма принимается даже тогда, когда округление даёт нулевой новый USD-credit. При недоступной цене donation также принимается, но может дать нулевой новый capacity credit.

USD-credit donation считается по меньшей из spot и эталонной цены, поэтому разогнанная внутри транзакции цена не увеличивает boost.

После WindDown donation не принимается: новые позиции уже невозможны, и переданные GF были бы просто навсегда заблокированы.

#13.2 Выкуп в резерв из комиссий создателя

Pons отчисляет создателю токена часть торговых комиссий GF (раздел 4.5). Размер этой доли задаёт Pons; она начисляется в USDG и хранится в эскроу комиссий Pons, пока получатель её не заберёт. Получатель доли создателя у GF — не команда, а отдельный неизменяемый контракт GongFuFeeCollector (сборщик комиссий). Он развёрнут до создания токена и указан получателем в той же транзакции, поэтому получает комиссии с первой сделки.

У сборщика нет владельца и нет функции вывода USDG кому-либо. Он умеет только:

• забрать накопленные USDG из эскроу Pons (claimFees);
• пока поколение Active, купить на них GF в пуле Uniswap V4 и перевести купленное прямо в контракт GongFu (buybackToReserve). Сделка проходит, только если куплено не меньше, чем следует из эталонной цены (раздел 14), минус 3% на проскальзывание; иначе она откатывается. Размер одного выкупа выбирает вызывающий, поэтому крупную сумму можно разбить на части;
• перевести в резерв GF, случайно оказавшиеся на сборщике (sweepGfToReserve);
• после WindDown переслать USDG в Мост следующего поколения (раздел 19.7).

Все функции может вызвать любой. Сменить получателя комиссий в Pons может только сам текущий получатель, а у сборщика такой функции нет.

Комиссии, начисленные до активации, копятся на сборщике в USDG и идут на выкуп после активации. Эталонная цена стартует с порога активации и догоняет рынок не быстрее чем на 25% в час, поэтому первые выкупы могут откатываться, пока она не приблизится к spot; её можно подтянуть вызовом observeReferencePrice.

Выкуп — это прямой перевод GF, а не вызов donation. Он увеличивает surplus так же, как donation, но не создаёт donation history и не даёт никому capacity boost. Объём выкупа зависит от торговой активности и не является гарантированным источником платёжеспособности: ни principal, ни claims от него не зависят.

Pons сохраняет за собой путь перехвата: владелец протокола Pons может сам назначить другого получателя комиссий создателя (по документации Pons — с задержкой 3 дня). Это граница доверия вне контроля GongFu (раздел 18.10). Перехват лишил бы резерв только будущего выкупа, но не затронул бы ни резерв, ни principal, ни claims.

Комиссии других рынков, бирж или launchpad вне кривой и пула Pons находятся вне ядра GongFu и не считаются источником платёжеспособности.

#14. Источник цены и рыночная стоимость

GF/USD цена нужна для MaxCap и для расчёта value multiple при Continue. Она не определяет principal и не требуется для защищённых claims. V1 использует один неизменяемый Uniswap V4 GF/USDG spot-маршрут, привязанный к закреплённым PoolManager и точному PoolKey; poolId вычисляется из PoolKey, а не передаётся пользователем. Маршрут читает slot0 и active liquidity, отклоняет malformed, uninitialized, out-of-bounds и low-liquidity состояния, а также промежуточное состояние unlocked, и fail-closed. Fallback и режим 60% отсутствуют. Маршрут закреплён за пулом GF/USDG, который Pons создаёт при выходе с кривой (раздел 4.5); до этого пул не инициализирован, маршрут fail-closed, и активация невозможна. Недоступность маршрута блокирует только новые Open и Continue; principal, Exit, settled reward, referral balance, settlement, WindDown и защищённые claims остаются price-free. Положительная donation принимается, но может дать нулевой capacity credit.

Сама spot-цена — не TWAP и не независимый oracle. Торговля, flash liquidity, hooks и same-block MEV могут сдвинуть её. Поэтому контракт хранит рядом с ней эталонную цену, которую нельзя сдвинуть внутри одной транзакции:

• эталонная цена движется только к spot, увиденной более ранними транзакциями, и не быстрее чем на 25% от себя в час;
• каждое наблюдение сначала ограничивается коридором ±25% вокруг эталонной цены, поэтому одна подстроенная транзакция сдвигает её максимум на 25%, сколько бы времени ни прошло;
• эталонная цена стартует с минимальной допустимой цены маршрута (порога активации) и поднимается оттуда.

Каждое значение, зависящее от цены, берёт ту из двух цен, которая менее выгодна вызывающему:

Сдвиг spot внутри своей транзакции поэтому не помогает тому, кто его сделал. Повторяющиеся манипуляции в тихий период могут постепенно сдвигать эталонную цену, но каждая такая попытка стоит комиссий и ограничена коридором. При быстром реальном движении рынка эталонная цена отстаёт на часы. В это время цена фиксации новых позиций может быть ниже рыночной, и тогда contribution при последующем Continue окажется немного выше. Bounds и liquidity floor маршрута сохраняются. Пользователь не выбирает PoolManager, токен, pool, цену или route.

#15. Безопасность смарт-контракта

#15.1 Отсутствие скрытого контроля

Production-контракт развёрнут без:

• owner или admin;
• proxy или upgrade;
• pause;
• rescue и generic withdrawal;
• delegatecall;
• selfdestruct;
• скрытого назначения ценового маршрута или получателей.

После развёртывания служебный адрес запуска может выполнить ровно два действия: при запуске один раз привязать сборщик комиссий к этому контракту (раздел 13.2) и один раз, только после WindDown, указать Мост следующего поколения для комиссий (раздел 19.7). GF, USDG и правила он изменить не может.

Неизменяемость защищает правила от разработчика, но делает ошибку неисправимой. Поэтому опубликованные source, bytecode и constructor manifest проверяются до взаимодействия. GongFu запускается без платной аудиторской компании: проверенный исходный код открыт по адресу контракта, а проверка доступна сообществу, исследователям безопасности и собственным инструментам любого участника, включая AI-агентов.

#15.2 Авторизация и токены

• Действия с principal и owner reward разрешены только владельцу позиции.
• Контракт использует msg.sender, а не tx.origin, поэтому поддерживаются contract wallets.
• Каждая позиция имеет уникальную пару owner/sequence и не переиспользуется.
• Входящие и исходящие GF проверяются по точным изменениям балансов.
• Fee-on-transfer, short transfer, malformed return и неожиданный callback отклоняются с полным rollback.
• Checks-effects-interactions и единая reentrancy-защита применяются ко всем token-moving маршрутам.
• Нулевая бухгалтерская диспозиция не вызывает ненужный ERC-20 transfer.

#15.3 Инварианты жизненного цикла

• Principal liability уменьшается только вместе с точной выплатой principal.
• MaxCap notional освобождается ровно один раз в той же успешной транзакции.
• Повторный claim, Exit, Continue или referral rollup отклоняется.
• Pending owner choice изменяется только вместе с точным флагом позиции.
• Referral liability может только перейти из maturity-окна в личный баланс или покинуть контракт через полный referral claim.
• Integer dust остаётся защищённым до одноразовой финализации окна.
• WindDown необратим.
• Ни одно действие не обходит неограниченный список пользователей или позиций; работа ограничена одной позицией, одним окном и максимум тремя referral-компонентами.

#15.4 Публичная проверка mainnet

Deployment manifest связывает:

• chain ID 4663;
• адрес и runtime code hash GongFu;
• адрес, decimals, total supply и runtime code hash GF;
• адрес канонического рынка;
• закреплённые Uniswap V4 PoolManager, USDG, производный poolId, PoolKey, price bounds и minimum active-liquidity параметры;
• хеш исходного кода и воспроизводимого байткода;
• explorer verification исходного кода и ссылки на независимые проверки по мере их публикации.

Интерфейс не заменяет эту проверку и не может подменять contract-derived значения собственными.

#16. Scenario Lab и границы моделирования

Публичная лаборатория GongFu - исследовательский stress-инструмент, а не маркетинговый прогноз. Она проверяет поведение конечного резерва при разных темпах притока, фиксации прибыли, прекращении участия и комбинированных шоках.

Обязательные инварианты модели:

• conservation фиксированного предложения GF;
• principal-first accounting;
• отсутствие раннего forced exit до maturity, кроме WindDown;
• contribution только из reward;
• внешние продажи меняют рынок, но не пополняют GongFu;
• постоянный participant profile на всех покупках и Continue;
• необратимый WindDown;
• отсутствие интерпретации результатов как прогноза FDV или доходности.

Симулятор не является production-источником цены и не определяет канонический рынок. Его результаты не прошиваются в контракт.

#17. Неизменяемые параметры V1

Ни один процент награды не является гарантией. Неизменяемость означает, что эти правила нельзя тихо заменить после активации.

#18. Риски и границы доверия

#18.1 Рыночный риск

Цена GF может значительно упасть. Ликвидность может исчезнуть, а продажа - дать сильное проскальзывание. Возврат того же количества GF не гарантирует сохранение долларовой стоимости.

#18.2 Риск spot-цены

Корректная V4 slot0 цена может отражать манипулируемый тонкий рынок. Это не TWAP и не независимый oracle. Эталонная цена (раздел 14) убирает выгоду от сдвига цены внутри одной транзакции, но не защищает от устойчивого изменения рынка. Её можно постепенно сдвигать повторными платными манипуляциями в период, когда больше никто не действует. Bounds и liquidity floor снижают, но не устраняют риск.

#18.3 L2-риск

Доступность транзакций зависит от Robinhood sequencer, RPC, Ethereum data availability и finality. Временная остановка или censorship может задержать claim, хотя правила GongFu сохраняют право владельца.

#18.4 Риск неизменяемого кода

Неизвестная ошибка в immutable-контракте не может быть исправлена через upgrade. Платного профессионального аудита при запуске нет. Независимая проверка сообществом, исследователями или AI-инструментами уменьшает риск, но не устраняет его полностью.

#18.5 Риск ключа

Контракт не восстанавливает кошелёк. Потерянный ключ оставляет principal или referral balance защищённым в учёте, но делает подпись владельца невозможной.

#18.6 Gas и liveness

Пользователь оплачивает транзакции самостоятельно. Расчёт созревших окон встроен во вклады, продления и выход с наградой, а отмена окон после WindDown — в вывод, поэтому для движения очереди не нужен отдельный бот. Если перед окном участника накопилось больше 32 нерассчитанных окон, их сначала рассчитывает отдельный вызов, который может сделать любой, в том числе сайт. Транзакция, на которую выпал расчёт накопившихся окон, стоит дороже обычной. Высокий gas или нагрузка сети могут задерживать действия, но не превращают principal в surplus.

#18.7 Sybil и адресная идентичность

MaxCap, donation history и progression привязаны к адресу, а не к человеку. Один человек может использовать несколько кошельков, однако каждый адрес отдельно начинает с 7-дневного history-уровня; optional 1-дневная позиция не продвигает history. Каждый адрес подчиняется своему MaxCap. Прогрев многих адресов крошечными позициями открывает им длинные сроки, но лимит сверх стартовых 20% растёт только вместе с реально продлёнными суммами (раздел 7). Это ограничение, а не защита от Sybil: несколько адресов одного человека по-прежнему получают каждый свой стартовый лимит. То же касается рефералов: человек может пригласить свои же кошельки и получать до 12% их наград.

#18.8 Правовой и налоговый риск

Правила владения и налогообложения цифровых активов зависят от юрисдикции. Участник самостоятельно оценивает применимые требования.

#18.9 Риск следующего поколения

Запуск следующего поколения (раздел 19) — отдельное событие после WindDown, а не функция этого контракта. Он может задержаться или не состояться из-за технических, рыночных или внешних причин. Это не меняет ни одного обязательства текущего поколения: principal, settled rewards и referral-балансы остаются защищёнными и доступными по правилам этого документа. Приоритет в следующем поколении не является компенсацией падения цены GF и не гарантирует доход.

#18.10 Риск launchpad Pons

Рынок GF создаёт сторонний launchpad Pons, и GongFu не контролирует его код:

• владелец протокола Pons может назначить другого получателя комиссий создателя (по документации Pons — с задержкой 3 дня). Тогда выкуп в резерв из комиссий прекратится; резерв, principal и claims это не затрагивает;
• контракты Pons V2 на момент написания не прошли опубликованного аудита. Ошибка в кривой, хуке или пуле Pons может повлиять на рынок GF и, через маршрут цены, на возможность новых Open и Continue;
• Pons может ограничить круг адресов, которым разрешён запуск. Набор запуска проверяет это до первой транзакции; если запуск закрыт, он не начнётся;
• между покупкой резерва и его переводом в GongFu проходит несколько минут, в течение которых 500 000 000 GF находятся на служебном адресе (раздел 4.3).

#19. Поколения: что происходит после WindDown

#19.1 Принцип

Каждое поколение GongFu конечно. Его резерв не пополняется эмиссией, а правила не меняются после активации. Когда reward-фаза поколения завершается через WindDown, эксперимент продолжается следующим поколением: новым протоколом с новым токеном и новым резервом.

Текущее поколение при этом не продлевается и не переписывается. Его контракт продолжает работать по своим неизменяемым правилам, пока каждый участник не заберёт свои GF. Следующее поколение не может изъять, перенести или «конвертировать» средства текущего.

#19.2 Неизменные обещания для любого следующего поколения

Какой бы ни была следующая версия, она обязана соблюдать следующие условия:

• нет владельца, администратора, апгрейда, паузы и скрытого вывода;
• principal участника учитывается отдельно от резерва и никогда не становится наградой другого участника;
• WindDown остаётся необратимым честным завершением reward-фазы;
• новый токен имеет фиксированное предложение, а не менее 50% этого предложения покупается в транзакции создания токена и в ходе того же запуска переводится в контракт нового поколения; команда из этой части ничего не оставляет себе;
• фиксированная доля предложения нового токена (корзина Моста поколений, раздел 19.4) направляется участникам текущего поколения по заранее объявленной формуле;
• запуск возможен только после того, как текущее поколение перешло в WindDown, и это условие проверяется по данным контракта;
• исходный код следующего поколения и Моста публикуется, верифицируется в обозревателе блоков и проходит независимый аудит до запуска.

#19.3 Два пути запуска

Базовый путь. Следующее поколение использует тот же проверенный код GongFu, что и текущее, с новым токеном и новыми параметрами рынка, плюс Мост поколений. Этот путь не требует новых решений и не зависит от создателя протокола. Набор запуска базового пути (параметры токена, рынка и порядок развёртывания) фиксируется до активации текущего поколения: его криптографический хеш публикуется в deployment manifest, а сам набор раскрывается не позднее момента запуска. Любой может сверить раскрытый набор с опубликованным хешем.

Улучшенный путь. Если к моменту WindDown готова улучшенная версия, прошедшая аудит, вместо базовой запускается она. Улучшения могут касаться параметров наград и лимитов, сроков, механики продолжения и глубины рынка. Они опираются на публичные on-chain данные работы текущего поколения. Улучшенная версия обязана соблюдать все условия раздела 19.2. Если она не готова, запускается базовый путь.

#19.4 Мост поколений: приоритет участников текущего поколения

Мост поколений — отдельный небольшой неизменяемый контракт следующего поколения. В ходе запуска нового токена он получает фиксированную корзину:

5% предложения нового токена

Корзина распределяется между участниками текущего поколения, которые недополучили награду из-за WindDown. Мост сам читает данные текущего контракта; ни список, ни суммы не составляются вручную.

Вес каждой позиции:

вес = principal позиции в GF
    × дни, в течение которых GF были реально заблокированы
      (до maturity или до WindDown, что наступило раньше)
    × недополученная доля максимальной награды

Недополученная доля равна:

• 100%, если окно позиции отменено WindDown;
• части, на которую была урезана награда, если окно рассчитано с пропорциональным коэффициентом;
• нулю, если позиция получила максимальную награду полностью или её максимальная награда равна нулю (слишком маленькая позиция).

У позиций на 90 и 180 дней недополученная доля считается по всем ежемесячным частям сразу: каждая часть входит со своим максимумом и той долей, которую не выплатило её окно. Например, если первая часть из трёх выплачена полностью, вторая наполовину, а третья отменена, недополученная доля равна 50%.

Учёт фактического времени блокировки делает бессмысленным вход «за день до конца» ради бонуса: недавно открытая позиция почти ничего не весит. Вес считается в GF, а не в долларах: цена в момент открытия на него не влияет, поэтому разогнать цену при входе ради большей доли нельзя. Дробление одной суммы на несколько адресов вес не увеличивает: он пропорционален количеству GF.

Мост активируется только после того, как текущее поколение вошло в WindDown, следующее поколение активировано и корзина поступила на адрес Моста.

Распределение проходит в два этапа:

1. Окно регистрации — 30 дней после активации Моста. Участник указывает свои позиции; Мост проверяет каждую по данным текущего контракта. Каждую позицию можно зарегистрировать один раз.
2. Распределение. После окна корзина делится пропорционально весам. Гонки нет: порядок регистрации не влияет на долю.

Получить свою долю может только адрес, зарегистрированный в следующем поколении. Это приоритет для тех, кто продолжает участие, а не выплата за уход. Забрать свою долю можно в течение 180 дней после закрытия окна регистрации. Всё, что осталось в корзине после этого срока (невостребованные доли и остатки округления), не возвращается команде: любой может вызвать перевод этого остатка в резерв следующего поколения. Если в окно регистрации не зарегистрирована ни одна позиция, корзина передаётся в резерв сразу после его закрытия.

#19.5 Кто запускает следующее поколение

Запуск выполняет служебный адрес, указанный в deployment manifest текущего поколения. Его роль техническая: он создаёт токен и развёртывает контракты по опубликованному набору. Он не оставляет себе токенов и не управляет резервом: в транзакции создания токена он покупает 55% предложения (50% для резерва и 5% для корзины Моста) и в ходе того же запуска переводит их на адреса контрактов. На покупку идут его собственные USDG. Отклонение от набора видно любому, кто сверит развёртывание с опубликованным хешем. После запуска этот же адрес один раз привязывает Мост следующего поколения к контракту текущего (раздел 19.7).

#19.6 Чего «Поколения» не обещают

• GF текущего поколения не конвертируется в токен следующего поколения;
• приоритет не компенсирует изменение цены GF и не является доходом;
• размер доли в корзине Моста заранее неизвестен: он зависит от числа и веса зарегистрированных позиций;
• следующее поколение тоже конечно и подчиняется тем же принципам.

#19.7 Комиссии после WindDown идут следующему поколению

После WindDown выкуп GF в резерв этого поколения больше не финансирует ничьих наград. Но рынок GF продолжает работать, и сделки продолжают приносить сборщику комиссий (раздел 13.2) USDG. Поэтому после WindDown сборщик перестаёт покупать GF и направляет USDG следующему поколению:

1. Остановка выкупа. Как только поколение вошло в WindDown, выкуп GF в его резерв (buybackToReserve) больше невозможен. USDG копятся на сборщике.
2. Привязка. Служебный адрес запуска (раздел 19.5) один раз и только после WindDown указывает Мост следующего поколения. Контракт проверяет, что этот Мост ссылается на текущее поколение как на предыдущее, а его следующее поколение уже запущено. Других полномочий у служебного адреса нет: он не может забрать GF или USDG, изменить правила или привязку.
3. Пересылка. Любой может вызвать у сборщика forwardToNextGeneration: весь USDG сборщика уходит в Мост, привязанный к контракту этого поколения. Другого адреса сборщик выбрать не может.
4. Выкуп в резерв. Любой может вызвать в Мосте buybackNextGenerationToken. Мост покупает токен следующего поколения на его рынке и переводит купленное прямо в его резерв как свободную ликвидность. Сделка проходит, только если куплено не меньше, чем следует из эталонной цены следующего поколения, минус 3% на проскальзывание; иначе она откатывается. Размер одного выкупа выбирает вызывающий, поэтому крупную сумму можно разбить на части. Эталонная цена следующего поколения обновляется его сделками и донатами; если их нет, любой может вызвать observeReferencePrice — это то же наблюдение цены, что делает любой донат, с теми же ограничениями (раздел 14).

Следующее поколение использует тот же код и свой сборщик, поэтому после его WindDown его комиссии так же уйдут дальше.

Этот поток не гарантирован. Его объём зависит от торговли GF после WindDown. До привязки USDG копится на сборщике этого поколения и не может уйти никуда, кроме привязанного Моста; если следующее поколение не будет запущено, USDG там и останется.

#19.8 Рефералы переходят в следующее поколение

Следующее поколение — новый контракт со своей регистрацией, но связи приглашений не теряются. Если при регистрации в следующем поколении человек не указал пригласившего, контракт сам читает, кто пригласил этот адрес в предыдущем поколении. Если тот уже зарегистрирован в новом поколении, он становится пригласившим, как при личном приглашении. Если ещё не зарегистрирован, работает обычная очередь (раздел 12). Пригласивший, указанный вручную, всегда важнее унаследованного.

Чтение предыдущего контракта ограничено по газу: любой сбой означает только то, что наследования нет, и регистрация проходит как обычно. Реферальные балансы предыдущего поколения не переносятся: их забирают в его контракте.

#20. Источники

1. Robinhood Chain: overview
2. Robinhood Chain: network connection
3. Robinhood Chain: smart-contract deployment
4. Uniswap v4 core: PoolId derivation
5. Uniswap v4 core: pool state reads
6. PROJECT_CHECKPOINT_v1.json и корневые протокольные документы GongFu.

#Заключение

GongFu не скрывает конечность резерва и не маскирует её бесконечной эмиссией. Он отделяет principal от surplus и заранее определяет честный конец reward-фазы. Ключевая идея проста: неизменяемые правила, прозрачная бухгалтерия и WindDown, при котором основная сумма не становится платой за чужой выход. А когда одно поколение честно завершается, следующее начинается по правилам, объявленным заранее.