Ваш ИИ-агент заработал $100к, а поставить его на баланс компании нельзя. Как мы создаем стандарт для капитализации алгоритмов (SOLPDT 1.1)

Пресс-релиз открытого стандарта SOLPDT 1.1 (Agentic Trust Layer). Приглашение к сотрудничеству.

1. Введение. Ваш ИИ-агент зарабатывает деньги, но для вашей компании он — пустое место

Представьте ситуацию: ваша команда разработала автономного ИИ-агента для арбитража на децентрализованных биржах Solana. Вы потратили $50 000 на зарплаты разработчиков и аренду инфраструктуры. Агент вышел на рабочий режим и начал стабильно приносить прибыль — скажем, $10 000 в месяц.

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

Это не ошибка конкретного бухгалтера. Это системный разрыв между скоростью развития технологий (особенно Web3 и ИИ) и консервативностью финансовых стандартов. Существующие стандарты, такие как МСФО (IAS 38) или российский ФСБУ 14/2022, говорят, что для признания Нематериального Актива (НМА) нужно доказать три вещи:

1. Идентифицируемость: Актив можно отделить от компании.
2. Контроль: Компания контролирует будущие выгоды от актива.
3. Будущие экономические выгоды: Существует высокая вероятность того, что актив будет приносить доход.

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

2. SOLPDT 1.1: криптографический «паспорт» для вашего ИИ-агента

SOLPDT 1.1 (Agentic Trust Layer) — это открытый стандарт, который решает описанную выше проблему. Если говорить просто, он позволяет создать для ИИ-агента криптографически верифицируемый цифровой паспорт, который одновременно является и техническим манифестом, и основанием для бухгалтерского учета.

В основе стандарта лежит иерархия доверия из трех уровней:

• Корневой узел (Root Authority) — создатель стандарта, который определяет методологию и аккредитует Головного Лицензиара.
• Уполномоченный Лицензиар (DAT-A) — технический аудитор, который проверяет вашего агента и выдает криптографическую подпись sig.a (Authoritative Attestation). Критерии аккредитации таких аудиторов детально описаны в Приложении O к спецификации SOLPDT.
• Ваш ИИ-агент — конечный бенефициар, который получает подпись sig.a и право быть признанным НМА.

Хотя в качестве примера мы используем агента на Solana (это одна из самых быстрорастущих экосистем для ИИ-агентов), сам стандарт SOLPDT 1.1 спроектирован как мультиплатформенный. Его архитектура не привязана жестко к конкретному блокчейну. В спецификации заложены принципы совместимости с ERC-8004 (стандарт для ИИ-агентов на Ethereum) и протоколом Google A2A (Agent-to-Agent). Поэтому «паспорт» skills.json может быть выдан агенту, работающему на любой технологической платформе.

Ключевым артефактом стандарта является файл skills.json. Это не просто текстовое описание. Это структурированный манифест, который:

• Содержит идентификаторы агента и его создателя в сети Solana.
• Описывает его навыки (skills) и ключевые метрики производительности (pdt_metrics), такие как процент успешных сделок или средняя прибыль.
• Содержит блок ias38_metadata, который напрямую связывает технические показатели агента с критериями признания Нематериального Актива по стандартам IAS 38 и ФСБУ 14/2022.
• Подписан приватным ключом создателя, что делает манифест юридически значимым документом.

Важно: Стандарт SOLPDT предоставляет техническую и методологическую основу для признания НМА. Окончательное решение о постановке на баланс и налоговые последствия зависят от законодательства конкретной юрисдикции и требуют консультации с профессиональным аудитором.

Сам по себе файл skills.json — это уже большой шаг вперед. Но чтобы он стал полноценным «паспортом», его необходимо верифицировать. Для этого мы будем использовать два инструмента:

• SOLPDT CLI — open-source утилита для генерации, подписания и локальной валидации манифеста.
• Compliance Gateway (CGW) — серверный валидатор, который проверяет подпись, сверяет заявленные метрики с ончейн-данными и выдает финальное заключение.

В следующем разделе я на конкретном примере покажу, как это работает.

3. Демонстрация. Создаем «паспорт» для арбитражного агента QuantuArbitrage

Давайте посмотрим, как это работает на практике. В качестве примера я возьму ИИ-агента QuantuArbitrage_LpBot, который занимается атомарным арбитражем между пулами ликвидности на Raydium, Orca и Meteora. Этот кейс — не абстрактная фантазия. Он является одним из эталонных пользовательских сценариев, детально описанных в Приложении N к спецификации SOLPDT 1.1. Мы намеренно выбрали его, чтобы показать, как стандарт работает на реальном, востребованном рынком примере, и приглашаем первых смельчаков проверить стандарт на своих проектах и, может быть, даже стать аккредитованными аудиторами (DAT-A).

Вот как выглядит его манифест skills.json, сгенерированный и подписанный с помощью нашей CLI-утилиты:

{
  "solpdt_version": "1.1.0",
  "agent": {
    "name": "QuantuArbitrage_LpBot",
    "creator_name": "QuantuArbitrage Ltd",
    "creator_pubkey": "QuantuArbi1111111111111111111111111111111",
    "agent_identity_pubkey": "BotX77777777777777777777777777777777777"
  },
  "skills": [
    {
      "skill_id": "SKILL-ARBI-001",
      "type": "cross-dex-arbitrage",
      "risk_level": "medium",
      "pdt_metrics": {
        "win_rate_pct": 92.4,
        "avg_profit_per_tx_sol": 0.045,
        "total_volume_generated_usd": 14200000
      }
    }
  ],
  "ias38_metadata": {
    "asset_class": "Intangible Asset / Идентифицируемый НМА",
    "recognition_criteria": {
      "identifiability": "Разделяемый программный код с криптографической идентичностью BotX777...",
      "control": "Исключительные права принадлежат QuantuArbitrage Ltd через владение приватным ключом Creator",
      "future_economic_benefits": "Генерация прибыли за счет арбитражного спреда на DEX (подтверждено ончейн-данными)"
    },
    "accounting_data": {
      "accounting_standard": "IAS 38 / ФСБУ 14/2022",
      "estimated_useful_life_months": 24,
      "amortization_method": "straight-line"
    }
  },
  "trust_layer_signature": "3vRzaB9Qp8...[Digital_Signature]..."
}

Что здесь важно для разных аудиторий:

Для разработчика (Web3/Solana):

• agent_identity_pubkey: У агента есть собственный кошелек, с которого он подписывает транзакции. Это техническая основа для его идентификации.
• pdt_metrics: Понятные, измеримые метрики успеха, которые можно проверить, заглянув в блокчейн.
• trust_layer_signature: Криптографическое доказательство того, что именно создатель (creator_pubkey) авторизовал этот манифест. Любое изменение файла сделает подпись невалидной.

Для бухгалтера и аудитора (ФСБУ/IAS):

• ias38_metadata.recognition_criteria.identifiability: Четко указывает, что актив отделим от компании, так как привязан к уникальному криптографическому идентификатору.
• ias38_metadata.recognition_criteria.control: Подтверждает, что компания контролирует актив, так как владеет приватным ключом creator_pubkey.
• ias38_metadata.recognition_criteria.future_economic_benefits: Связывает способность актива приносить доход с проверяемыми ончейн-метриками (pdt_metrics).
• accounting_data: Предоставляет готовые параметры для начисления амортизации.

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

4. Инструментарий. SOLPDT CLI — наш open-source проект для сообщества

Стандарт хорош тогда, когда им легко пользоваться. Чтобы разработчикам не приходилось вручную писать и валидировать JSON, мы запускаем open-source проект SOLPDT CLI — легкую утилиту командной строки на TypeScript/Node.js.

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

Какой мы видим утилиту (план разработки):

Утилита будет решать три ключевые задачи:

1. Генерация (команда solpdt init): В интерактивном режиме задает разработчику несколько вопросов об агенте (имя, тип навыка, публичный ключ создателя) и на основе ответов создает валидный шаблон манифеста skills.json.
2. Безопасное подписание (команда solpdt sign): Помогает подписать манифест приватным ключом, не компрометируя его. Будут поддержаны три режима: использование переменной окружения (SOLANA_PRIVATE_KEY), скрытый ввод в консоли и работа с аппаратными кошельками Ledger.
3. Локальная валидация (команда solpdt validate): Мгновенно проверяет манифест на синтаксические ошибки (JSON Schema) и корректность криптографической подписи (Ed25519). Это реализация нашего Light Validator, которая работает полностью офлайн.

Наша цель (как это будет выглядеть в терминале):

• Разработчик вводит команду solpdt init.
• Утилита в интерактивном режиме задает ему вопросы об агенте (имя, тип навыка, публичный ключ создателя).
• На основе ответов утилита создает валидный шаблон манифеста skills.json.
• Разработчик вводит команду solpdt sign ./skills.json.
• Утилита запрашивает приватный ключ (или берет его из переменной окружения) и подписывает манифест, добавляя в него поле trust_layer_signature.
• Разработчик вводит команду solpdt validate ./skills.json.
• Утилита проверяет JSON-схему, криптографическую подпись и публичный ключ, после чего выводит сообщение об успешной локальной проверке.

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

5. Под капотом. Как SOLPDT проверяет, что манифесту можно доверять

(Если вам не интересны технические детали валидации, можете смело переходить к Разделу 6)

Наличие подписи на JSON-файле — это хорошо, но недостаточно. Чтобы манифест skills.json стал юридически и технически значимым документом, он должен пройти многоступенчатую проверку. Мы называем этот процесс SOLPDT Compliance Gateway (CGW). Архитектура CGW спроектирована с учетом горизонтального масштабирования и кэширования (идемпотентность, TTL 48ч), что позволяет обрабатывать тысячи запросов.

Для локальной разработки и быстрой проверки мы реализовали Light Validator — его код уже встроен в нашу CLI-утилиту. Он выполняет три критических шага, которые отсекают 99% ошибок.

Шаг 1: Синтаксическая валидация (JSON Schema)

Первым делом валидатор проверяет, соответствует ли структура файла заданной JSON-схеме. Он убеждается, что:

• Все обязательные поля (solpdt_version, agent, skills) присутствуют.
• Типы данных корректны (например, win_rate_pct — это число, а не строка).
• Форматы строк соответствуют ожидаемым (например, публичный ключ — это строка Base58).

Для этого мы используем библиотеку ajv — самый быстрый JSON-валидатор в мире JavaScript.

Шаг 2: Канонизация и проверка подписи (Ed25519)

Это самый важный и тонкий момент. Чтобы проверить подпись trust_layer_signature, валидатору нужно вычислить точно такой же хеш, который был подписан создателем. Проблема в том, что JSON-объекты могут иметь разное форматирование (пробелы, переносы строк, порядок ключей), и все это изменит хеш.

Поэтому перед проверкой валидатор выполняет канонизацию документа:

1. Из объекта удаляется поле trust_layer_signature.
2. Все ключи в объекте сортируются в алфавитном порядке (это гарантирует одинаковый порядок).
3. Удаляются все незначащие пробелы.

В результате получается детерминированная строка, хеш от которой будет идентичен тому, что был подписан. Затем с помощью криптографической библиотеки @noble/curves (современный и безопасный стандарт) валидатор проверяет сигнатуру Ed25519, используя публичный ключ creator_pubkey из манифеста.

Шаг 3: Проверка ключей (Solana Web3)

На этом этапе валидатор проверяет, что публичные ключи (creator_pubkey и agent_identity_pubkey), указанные в манифесте, являются валидными адресами в сети Solana (лежат на кривой Ed25519). Для этого используется метод PublicKey.isOnCurve() из библиотеки @solana/web3.js.

Что дальше? Полный валидатор (Compliance Gateway)

Описанные три шага — это «легкая» версия проверки. Полноценный Compliance Gateway на сервере выполняет еще два критически важных шага, которые требуют доступа к RPC-ноде Solana (пользователь может использовать публичные ноды, такие как Helius или QuickNode, либо поднять свою собственную):

4. Верификация транзакций: Проверяет, что транзакция, указанная в манифесте как доказательство (last_verified_tx), действительно существует в блокчейне, имеет статус Finalized и была подписана агентом (agent_identity_pubkey).
5. Сверка PDT-метрик: Сравнивает заявленные в манифесте показатели (например, прибыль от сделки) с реальными данными из логов транзакции.

Только после успешного прохождения всех 5 шагов CGW выдает финальный сертификат верификации, который может быть использован для аудита и постановки агента на баланс как НМА.

6. Для прагматиков: ответы на частые вопросы (и где искать детали)

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

7. Присоединяйтесь к созданию стандарта для экономики ИИ-агентов

Мы находимся в уникальной точке. ИИ-агенты уже здесь, они совершают миллионы транзакций и генерируют реальную ценность. Но инфраструктура для их «взрослой», легальной жизни в корпоративном мире только создается. SOLPDT 1.1 — это попытка построить мост между хаотичным, но инновационным миром Web3 и строгим, но необходимым миром финансового учета.

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