Karak известен как протокол restaking, где операторы использовали депонированные активы для экономической защиты Distributed Secure Services, или DSS. Однако актуальный статус проекта изменился: в ноябре 2025 года команда объявила ребрендинг Karak в OpenGDP и расширила направление до инфраструктуры программируемой экономики. Старые приложения staking и документация Karak продолжают работать, но главный домен уже ведёт на OpenGDP.
Поэтому обзор нужно читать в двух слоях. Первый – действующая архитектура Karak V1 и V2 с vaults, операторами, DSS и механизмом slashing. Второй – новый OpenGDP Network Stack, который заявлен как платформа для токенизации, расчётов, управления правилами и запуска специализированных сетей. Это одна линия развития, но не один и тот же набор функций.
Как работала restaking-модель Karak
Пользователь вносил поддерживаемый актив в vault, связанный с оператором. Vault учитывал доли вкладчиков, а оператор регистрировал его в выбранных DSS. Один и тот же restaked капитал мог использоваться как общее экономическое обеспечение нескольких сервисов. За выполнение задач DSS мог назначать операторам вознаграждения, а за доказанное нарушение – запрашивать наказание.
Distributed Secure Service в терминологии Karak – внешний сервис, который использует операторов и обеспечение протокола. Это мог быть механизм доступности данных, мост, oracle или другая распределённая система. DSS сам определял полезную работу, критерии нарушения и форму rewards, а Karak Core предоставлял интерфейсы для регистрации stake и исполнения наказаний.
Такой дизайн снижал порог запуска сервиса: разработчику не обязательно было с нуля формировать отдельный набор экономического обеспечения. Обратная сторона – общий капитал связывал риски разных DSS. Если оператор обслуживал несколько систем, одно обеспечение могло поддерживать несколько обязательств, которые нельзя считать независимыми.
Vaults, операторы и вывод средств
Токенизированный vault Karak строился вокруг ERC-4626 и закреплялся за конкретным оператором. Вклад в такой vault означал делегирование этому оператору. Состав активов, подключённые DSS и качество оператора определяли профиль позиции сильнее, чем название базового протокола.
Документация также описывает NativeVault для нативного restaking и возможность создавать совместимые пользовательские реализации. Надстройки LRT могли объединять депозиты, выдавать свой receipt token и распределять активы между операторскими vaults. В такой схеме добавлялись полномочия администратора LRT, риск его контрактов и собственная очередь вывода.
Вывод средств в Karak был асинхронным: запрос создавался отдельно, а получение происходило после предусмотренного системой ожидания. Точный актуальный порядок нужно проверять в используемой версии приложения и контракта. Нельзя переносить параметры одного vault на другой или обещать единый срок для всей экосистемы.
Как DSS мог наказать оператора
DSS формировал запрос slashing с оператором, списком vaults и долями наказания. После запроса предусматривалось окно для рассмотрения комитетом, способным наложить veto. Если запрос не отклонён, отдельная операция завершала наказание. Эта конструкция давала время отсеять ошибочный запрос, но одновременно добавляла доверие к составу и работе комитета.
Slashing важен не только как техническая функция. Пользователь должен понимать, за какую работу отвечает оператор, какое доказательство нарушения принимает DSS и какую максимальную долю позиции можно потерять. Если vault зарегистрирован в нескольких сервисах, риски могут быть связаны общей инфраструктурой и одним оператором. Подробнее этот эффект разобран в материале о коррелированном slashing в restaking.
Rewards при этом не распределялись единым механизмом Karak Core. DSS мог задавать собственную форму и порядок вознаграждений. Показанная доходность могла включать базовый доход актива, стимулы партнёра или points. Пример того, как разделять источники результата, даёт обзор продуктов Spark.
Что изменил переход к OpenGDP
Официальное объявление описывает OpenGDP как развитие Karak с той же командой и общей кодовой линией, а не как внезапный новый проект. Акцент сместился с одного restaking-продукта на базовый слой для токенизации реальных активов, обмена, расчётов и многосторонних процессов. OpenGDP Network Stack предназначен для запуска специализированных сетей с собственными правилами, приватностью и доступом к общей инфраструктуре.
Главный сайт теперь говорит о перемещении стоимости, выпуске программируемых инструментов и координации экономических процессов. В навигации при этом сохранены ссылки на V1 Staking, V2 Staking и мост K2. Это показывает переходный характер экосистемы: старые restaking-компоненты не исчезли мгновенно, но больше не определяют всю публичную концепцию проекта.
Для исследователя это означает необходимость фиксировать дату и версию. Старый материал про «Karak как универсальный restaking layer» может корректно описывать контракты V1, но уже неверно передаёт стратегию бренда. А заявления OpenGDP о будущей институциональной инфраструктуре нельзя автоматически считать характеристиками действующего staking-приложения.
Существует ли токен KAR
Тикер KAR был заложен в ранний редакционный план, но официальное приложение Karak прямо предупреждало, что живого токена Karak нет. После ребрендинга фонд представил направление дизайна актива GDP, одновременно указав, что в момент объявления этот токен не существовал и не был доступен для покупки или получения.
Следовательно, ни KAR, ни произвольный токен с похожим названием нельзя считать официальным активом проекта без нового объявления и подтверждённого адреса контракта. XP и другие баллы программы также не равны токену и не гарантируют конвертацию. Любое предложение «забрать KAR» через подпись или внесение seed-фразы следует считать признаком фишинга.
Даже после официального запуска токена нужно отдельно проверить его сеть, контракт, назначение, предложение и распределение. Символ тикера не уникален, а данные децентрализованной биржи не заменяют сообщение фонда. Без этих проверок обсуждение капитализации или доходности было бы выдумкой.
Как оценивать оставшиеся позиции Karak
Сначала определите, где находится позиция: в V1, V2, K2, операторском vault или LRT-надстройке. Запишите адреса контрактов, базовый актив и оператора. Затем выясните, в каких DSS зарегистрирован vault, кто задаёт rewards и какие условия slashing действуют. Для прокси-контрактов пригодна инструкция о том, как найти admin и implementation.
Проверьте текущий маршрут вывода через официальное приложение, не используя ссылки из личных сообщений. При переходе бренда особенно легко попасть на поддельный домен, который копирует старый интерфейс. Адрес назначения и разрешения токена следует подтверждать в обозревателе. Если транзакция проходит через multisig проекта, полезно проверить владельцев и порог подписей.
Karak остаётся важным примером restaking-архитектуры, но в 2026 году его нельзя описывать без OpenGDP. Для существующего вкладчика практическое значение имеют старые контракты и условия vault. Для оценки будущего проекта важнее новый сетевой курс. Смешивание этих двух уровней создаёт ложное впечатление, что все заявленные возможности уже работают в одном продукте.
