SOLPDT 1.1 | AGENTIC TRUST LAYER EXTENSION
SOLANA | ERC-8004 | SAR | SDP | Google A2A

SOLPDT 1.1: Agentic Trust Layer Extension
Техническая спецификация (Annex к v1.0)

Полная спецификация криптографического контейнера Payload-V2, экономических доказательств settlement_context, автоматизированного шлюза верификации Compliance-Gateway (CGW) с AML-фильтрацией, реестра отозванного доверия (TRL), механизма слэшинга и признания Нематериальных Активов (НМА) по стандартам IAS 38 и ФСБУ 14/2022.

СТАТУС: Действующее дополнение | Полная обратная совместимость с SOLPDT v1.0 (E-E-A-T 2.0)
КОРНЕВОЙ УЗЕЛ (СОЗДАТЕЛЬ СТАНДАРТА): Юрий Соколов (SOL Trust Network)
СОВМЕСТИМОСТЬ: ERC-8004, Solana Agent Registry (SAR), Solana Developer Platform (SDP), Google A2A Protocol
ДАТА ВСТУПЛЕНИЯ В СИЛУ: 20.04.2026

Преамбула. Основания для выпуска Annex 1.1

Дата фиксации: 20.04.2026

Основания для выпуска

Настоящее дополнение выпускается Корневым узлом (Создателем стандарта) в связи с необходимостью адаптации стандарта SOLPDT к текущему состоянию экосистемы Solana и запросам рынка.

Технологические предпосылки

  1. Развитие инфраструктуры Solana — публичный запуск Solana Agent Registry (SAR) и Solana Developer Platform (SDP).
  2. Целевые инфраструктуры — совместимость с ZK-сжатием Photon (Helius) и реестром ERC-8004 (Quantu AI).
  3. Сложившиеся практики разработки — стандартизация skills.json и solana-agent-kit.
  4. Запрос рынка на юридическое признание — потребность в признании результатов работы ИИ-агентов в качестве НМА по МСФО (IAS 38) и ФСБУ 14/2022.

Принцип обратной совместимости

Все существующие реализации SOLPDT v1.0 продолжают работать без изменений. Версия 1.1 добавляет слой финансовых гарантий, не ломая старый функционал. Агенты могут продолжать использовать старый формат метаданных, но для доступа к расширенным функциям экосистемы (включая приоритетный доступ к ликвидности через партнерские платформы) и признания НМА требуется активация Payload-V2.

Иерархия подписей (Delegated Trust)

УровеньКто подписываетЧто подписываетГде хранится
1. Корневая аккредитацияКорневой узел (Соколов Ю.И.)DAT-H (Digital Access Token — Head) для Головного ЛицензиараSTN Registry (Корневой реестр)
2. СублицензированиеГоловной Лицензиар (держатель DAT-H)DAT-M и DAT-A для ЛицензиаровSTN Registry (Реестр Головного Лицензиара)
3. Верификация агентаУполномоченный Лицензиар (держатель DAT-A)sig.a (Authoritative Attestation)В Payload-V2
4. Действие агентаАгент (владелец приватного ключа)tx_id и Payload-V2Блокчейн Solana

Примечание: Полная спецификация ролей (Корневой узел, Головной Лицензиар, Мастер-Лицензиар, Уполномоченный Лицензиар) и типов токенов DAT (DAT-H, DAT-M, DAT-A) приведена в Приложении O.

1. Введение

Спецификация SOLPDT 1.1 расширяет базовый протокол v1.0, внедряя прикладной слой SOLPDT-Payload-V2 и механизмы финансовой верификации. Данное обновление формализует взаимодействие ИИ-агентов с финансовыми системами экосистемы Solana (SDP, SAR) и закрепляет стандарт децентрализованных реестров навыков (skills.json).

Ключевые нововведения:

  • Криптографический контейнер Payload-V2 для доказательства результативности
  • settlement_context — экономические доказательства (связь с оплатой)
  • Автоматизированный Compliance-Gateway (CGW) с AML-фильтром
  • Trust-Revocation-List (TRL) и механизм слэшинга
  • Признание верифицированных результатов Нематериальными Активами (НМА) по МСФО (IAS 38)
  • Authoritative Attestation — подпись Уполномоченного Лицензиара (DAT-A)
  • Идемпотентность и кэширование (TTL = 48 часов)
  • Стандартизированные коды ошибок для автоматической обработки агентами

1.1. Ключевые инсайты (для технических директоров и архитекторов)

Готовность к протоколу x402 (v1.2)

Архитектура settlement_context и механизм идемпотентности спроектированы с возможностью расширения. Поле settlement_context является расширяемым (extensible): неизвестные ключи (например, будущие параметры x402) игнорируются парсерами v1.1, что позволяет бесшовно перейти к микротранзакциям и автоматическим расчётам между машинами (M2M) в версии 1.2.

Эффективное кэширование транзакций (TTL = 48 часов)

Compliance-Gateway поддерживает реестр идемпотентности, связывающий Payload_Hash и tx_id. Повторные запросы верификации не спамят RPC-ноды Solana и не требуют повторной оплаты. Время отклика Gateway для повторных запросов сокращается с секунд до миллисекунд (Cache Hit).

2. Спецификация формата данных Payload-V2

2.1. Объектная модель (JSON)

Payload-V2 передаётся в минимизированном JSON (поле memo транзакции Solana). Размер ограничен 566 байтами.

КлючПолеТипОбязательностьОписание
vVersionStringДаВерсия протокола (фиксировано "1.1")
pProtocolStringДаИдентификатор стандарта (фиксировано "SOLPDT")
hPAHHex StringДаPayload-Attestation-Hash. Хэш от skills.json + seed + nonce
sigSignaturesObjectДаОбъект, содержащий подпись валидатора
sig.aAuthSigBase58ДаAuthoritative Attestation. Подпись Уполномоченного Лицензиара (DAT-A), подтверждающая, что агент соответствует методологии SOLPDT.
dDataObjectДаМетрики производительности
d.sScoreFloatДаPDT-Score (0–1) — коэффициент эффективности агента
d.drDriftFloatДаPDT-Drift — отклонение текущего Score от среднего
nmaNMA StatusBooleanДаПризнак соответствия НМА (IAS 38). Только при наличии sig.a
uriVerify URIURLНетСсылка на публичный отчёт верификации
settlement_contextSettlementObjectНетЭкономические доказательства (см. п. 2.2)

2.2. Поле settlement_context (экономические доказательства)

Поле обеспечивает связь между верификацией и фактом оплаты. Является расширяемым (extensible): неизвестные ключи игнорируются.

КлючТипОбязательностьОписание
versionStringДаВерсия схемы (фиксировано "1.1")
methodStringДаСпособ оплаты: "on-chain-direct" или "subscription"
tx_idStringДа (для on-chain-direct)Signature транзакции в Solana
subscription_idStringДа (для subscription)ID контракта в биллинге Gateway
currencyStringНетТикер актива (по умолчанию "USDC")
amountNumberНетСумма для кросс-чека

Правила валидации:

  • Если method = "on-chain-direct", поле tx_id обязательно.
  • Если method = "subscription", поле subscription_id обязательно.
  • Gateway проверяет tx_id в блокчейне Solana (подтверждение, сумма, отправитель).
  • Time-window для tx_id — 48 часов. Транзакции старше этого окна не принимаются.

2.2.1. Типы комиссий и экономическая модель (Fee Architecture)

Стандарт SOLPDT 1.1 предусматривает четыре типа сборов, которые обеспечивают устойчивость экосистемы Agentic Trust Layer. Комиссии автоматически удерживаются и распределяются через смарт-контракт в момент финализации транзакции.

Тип сбораПлательщикПолучатель(и)Механизм фиксацииНазначение
Registration Fee
(Protocol Entrance)
АгентЛицензиарРазовый платёж при выпуске sig.aПредотвращение Sybil-атак, покрытие затрат на первичный аудит
Verification Fee
(Operational)
АгентЛицензиар, операторы CGWПлата за каждый вызов Compliance-GatewayОбеспечение работы шлюза верификации
Subscription Fee
(Trust Maintenance)
АгентЛицензиарРегулярный платёж через method = "subscription"Поддержание статуса «Active» в реестре
Success Royalty
(Performance-based)
АгентСоздатель стандарта, ЛицензиарПроцент от чистой прибыли агента (см. Приложение D)Роялти за использование методологии
Slashing
(Safety Deposit)
АгентПострадавшая сторона / Фонд сетиЗалог, списываемый при внесении в TRLОбеспечение экономической ответственности

Принципы распределения:

  • Все комиссии, кроме Slashing, распределяются автоматически в момент финализации транзакции.
  • Конкретные ставки (проценты, фиксированные суммы, лимиты) и валюты расчётов не фиксируются в спецификации. Они публикуются в отдельном документе «Тарифы и лицензии SOLPDT» (/tariffs) и могут изменяться без обновления версии стандарта.
  • Slashing осуществляется по правилам, описанным в разделе 4.5, и не зависит от тарифной политики.
Примечание для разработчиков: При реализации необходимо предусмотреть возможность чтения актуальных ставок из внешнего конфигурационного источника (оракула или реестра параметров).

2.3. Примеры реализации

Базовый пример Payload-V2 (без settlement_context)

{
  "v": "1.1",
  "p": "SOLPDT",
  "h": "0x7a3f8e2c9b1d5a6e4f8c3b2a1d5e7f9c2b4a6d8e",
  "sig": { "a": "3mQrP9xYtZv7wK1LmNpQ2rS5tU8vW2xYz4A6B8C0D" },
  "d": { "s": 0.98, "dr": 0.01 },
  "nma": true,
  "uri": "https://solpdt.com/verify/0x7a3f8e2c"
}

Пример с settlement_context (прямая оплата)

{
  "v": "1.1",
  "p": "SOLPDT",
  "h": "0x7a3f8e2c9b1d5a6e4f8c3b2a1d5e7f9c2b4a6d8e",
  "sig": { "a": "3mQrP9xYtZv7wK1LmNpQ2rS5tU8vW2xYz4A6B8C0D" },
  "d": { "s": 0.98, "dr": 0.01 },
  "nma": true,
  "uri": "https://solpdt.com/verify/0x7a3f8e2c",
  "settlement_context": {
    "version": "1.1",
    "method": "on-chain-direct",
    "tx_id": "5kP9xYtZv7wK1LmNpQ2rS5tU8vW2xYz4A6B8C0D",
    "currency": "USDC"
  }
}

Расширенный пример для целей НМА (с полным аудиторским следом)

{
  "solpdt_payload_header": { "v": "1.1", "cid": "bafy...", "ts": "2026-04-10T12:00:00Z" },
  "agent_context": { "agent_id": "8xJv...6YpW", "skill_id": "dex_arbitrage_v2" },
  "execution_proof": { "intent": "Arb gap...", "input_amount": "100.00 SOL" },
  "compliance_gate": { "aml_check": "PASS", "elliptic_ref": "tx-risk-0.01" },
  "auth_signature": "base58_signature_from_agent_key",
  "settlement_context": { "version": "1.1", "method": "on-chain-direct", "tx_id": "5kP9xYtZ..." }
}

2.4. Модель верификации: Делегированное доверие (Delegated Trust)

В версии SOLPDT 1.1 процедура коллегиального подтверждения транзакций заменена на модель делегированного доверия через Authoritative Attestation (sig.a).

2.4.1. Механизм исключения коллегиальной подписи

Необходимость в агрегированной подписи узлов STN упразднена на основании принципов:

  • Пре-валидация через DAT: Полномочия Лицензиара подтверждены токеном DAT.
  • Транзитивность доверия: Подпись sig.a эквивалентна одобрению всей сети STN.
  • Атомарность: Проверка одного ключа требует меньше ресурсов.

2.4.2. Роль DAT в архитектуре

Система проверяет статус Лицензиара в Реестре аккредитованных узлов. Если DAT Лицензиара активен (не отозван в TRL), любая подпись sig.a, созданная этим Лицензиаром, признаётся системой как доверенная.

2.4.3. Цепочка доверия (Trust Chain Validation)

Проверка транзакции в SOLPDT 1.1 основана на следующей иерархической цепочке доверия:

  • Аккредитация Головного Лицензиара: Корневой узел (Создатель стандарта) выдает мастер-лицензию DAT-H Головному Лицензиару. Это единственный прямой мандат от Корневого узла операционному звену.
  • Сублицензирование: Головной Лицензиар (держатель DAT-H) на основе своего мандата выдает операционные лицензии DAT-A Уполномоченным Лицензиарам для верификации ИИ-агентов.
  • Аттестация агента: Уполномоченный Лицензиар (держатель DAT-A) проверяет Агента (Handshake) и выдает ему криптографическую подпись sig.a.
  • Верификация транзакции: При совершении транзакции Compliance-Gateway проверяет валидность связки: [sig.a] → [DAT-A активен и не отозван] → [DAT-A выдан держателем DAT-H] → [DAT-H активен].

2.4.4. Алгоритм верификации Payload (Обновлённый)

  1. Format Check — соответствие JSON-схеме v1.1.
  2. DAT & Signature Auth — проверка DAT Лицензиара и декодирование sig.a.
  3. Hash Match — соответствие хэша h актуальной версии skills.json.
  4. TRL Check — отсутствие Pubkey агента и Лицензиара в TRL.
  5. Settlement Check (если есть settlement_context).

2.4.5. Экономическая ответственность Лицензиара

Уполномоченные Лицензиары (DAT-A) несут экономическую ответственность за умышленный подлог или грубое нарушение методологии в форме слэшинга (Slashing) своего гарантийного депозита.

При подтверждении нарушения:

  • 100% Stake Лицензиара переводится на SLASHING_POOL_ADDRESS (фонд компенсаций пострадавшим сторонам или сжигается).
  • Лицензия DAT-A аннулируется, а адрес вносится в TRL навсегда (статус PERMANENT).
Детальная спецификация: Полное описание процедуры слэшинга, условий его применения и классификация событий приведены в Приложении F (Протокол списания) и Приложении O (Иерархия ролей и типы DAT).

2.5. Интеграция с ERC-8004 (Cross-Chain Mapping)

Payload-V2 полеERC-8004 местоНазначение
h (PAH)metadata.provenanceХэш, связывающий off-chain манифест с ончейн-транзакцией
sig.a (AuthSig)attestations[] (тип Authoritative)Подпись Лицензиара, дающая приоритетный статус доверия
nma: trueasset_class: "intangible"Флаг признания актива НМА по IAS 38
d.s (Score)reputation.scoreКоэффициент эффективности агента

2.5.1. Совместимость с Google A2A Protocol

Стандарт SOLPDT спроектирован с учётом технической совместимости с протоколом Google Agent-to-Agent (A2A). AgentCard поддерживает произвольные расширения через объект extendedCapabilities.

SOLPDT-Payload-V2 (JSON-LD + Ed25519) технически может быть встроен как extension с URI https://solpdt.com.

📋 Подробная спецификация: Полное описание интеграции приведено в Приложении L.

2.6. Юридико-финансовое соответствие (Compliance Mapping)

Поле в JSONФинансовое значениеОснование (IAS 38 / ФСБУ)
sig.aПервичный документПодтверждает проверку актива Уполномоченным Лицензиаром
d.s (Score)Оценка полезностиДоказывает наличие будущих экономических выгод
nma: trueКлассификатор активаПрошёл критерии идентификации
h (PAH)Инвентарный номерУникальный идентификатор
uriАудиторский следСсылка для внешней проверки
settlement_context.tx_idЦифровое платежное поручениеПодтверждение фактических затрат
ЗНАЧЕНИЕ ДЛЯ БИЗНЕСА: Бухгалтер или аудитор, видя sig.a и nma: true, может легитимно провести актив по счёту 04 (Нематериальные активы).

3. Процедура валидации через Compliance-Gateway (CGW)

3.1. Этап 1: Инициация (Discovery & Request)

CGW проверяет доступность файла skills.json по адресу https://domain.com/.well-known/solpdt/.

3.2. Этап 2: Слой гигиены (Risk & AML Filter)

AML-скрининг, TRL-чек, проверка лимитов риска (например, max_drawdown не более 15%). При превышении допустимого порога риска (например, >7/10) процесс прерывается.

3.3. Этап 3: Методологический аудит (PDT-Engine)

Расчёт PDT-Score, проверка Drift (например, dr > 0.3 не допускается), накопление доказательств. Для признания НМА требуется статистически значимое количество успешных транзакций с PDT-Score выше порога (например, 5000 транзакций с Score > 0.7).

3.4. Этап 4: Финализация (Authoritative Signing)

Генерация подписи sig.a Уполномоченным Лицензиаром (DAT-A) и регистрация в SAR.

4. Механизм автоматического отзыва доверия (TRL)

4.1. Триггеры активации TRL

ТриггерУсловие (примеры порогов)Статус
Critical PDT-DriftPDT-Score падает ниже критического порога (например, 0.4) в течение установленного периода (например, 3 цикла)SUSPENDED
Compliance-BreachСигнал о связи кошелька с фродом или санкциямиPERMANENT
Skills-InconsistencyРасхождение данных skills.json с блокчейномSUSPENDED
Превышение лимитов рискаПревышение max_drawdown (например, более 15%)PERMANENT

4.2. Протокол исполнения (Kill-Switch)

Отправка Revocation Transaction в Solana, инвалидация sig.a, синхронизация с SAR/ERC-8004.

4.3. Финансовые и юридические последствия

Утрата статуса НМА, агентная изоляция, репутационный ущерб.

4.4. Процедура апелляции и восстановления (Re-Attestation)

Выход из TRL возможен только через переаттестацию у Уполномоченного Лицензиара (DAT-A).

5. Правовой статус и признание Нематериального Актива (НМА)

5.1. Основания для признания НМА по МСФО (IAS 38)

Критерий IAS 38Реализация в SOLPDT
Идентифицируемость (п.12)Уникальный agent_id + криптографический хэш Payload-V2 (PAH)
Контроль (п.13)Владение приватным ключом, подписывающим транзакции агента
Будущие экономические выгоды (п.17)PDT-Score выше установленного порога (например, 0.7) на протяжении статистически значимого количества транзакций (например, 5000)

5.2. Роль Authoritative Attestation

Признание актива как НМА возможно только при наличии sig.a — подписи Уполномоченного Лицензиара (DAT-A).

ПРАВИЛО: Нет sig.a — нет НМА.

5.3. Рекомендации по амортизации

Срок полезного использования определяется учётной политикой (например, 18 месяцев). Тест на обесценение запускается при падении PDT-Score ниже критического порога (например, 0.5) в течение установленного периода (например, 30 дней).

5.4. Шаблон Акта верификации НМА

Полный шаблон доступен в Приложении J.

6. Идемпотентность и кэширование

6.1. Принцип идемпотентности

CGW поддерживает реестр идемпотентности с TTL = 48 часов.

6.2. Защита от replay-атак

Кэш привязывает tx_id к конкретному Payload_Hash.

6.3. HTTP-заголовки

X-Cache-Status: MISS (или HIT)
X-Cache-TTL-Remaining: 172800

6.4. Пример успешного ответа с заголовками

HTTP Status: 200 OK
X-Cache-Status: MISS
X-Cache-TTL-Remaining: 172800
{
  "status": "success",
  "data": {
    "attestation": "SIG_ED25519_...",
    "pdt_score_updated": 0.892,
    "settlement_status": { "state": "settled", "method": "on-chain-direct" }
  }
}

7. Ошибки Compliance-Gateway и Handshake

7.1. Коды ошибок и HTTP-статусы

Код ошибкиHTTP статусСмысл
PDT_ERR_SETTLEMENT_MISSING400Отсутствует settlement_context
PDT_ERR_METHOD_NOT_SUPPORTED400Метод оплаты не поддерживается
PDT_ERR_TX_NOT_FOUND404Транзакция не найдена в сети
PDT_ERR_INSUFFICIENT_FUNDS402Сумма в tx_id меньше требуемой
PDT_ERR_INVALID_PAYLOAD400Отсутствует tx_id или version
PDT_ERR_SUBSCRIPTION_EXPIRED403Срок подписки истёк
PDT_ERR_SUBSCRIPTION_LIMIT_REACHED429Лимит операций подписки исчерпан
PDT_ERR_SUBSCRIPTION_NOT_FOUND404subscription_id не существует
HS_ERR_MISSING_FIELDS400Отсутствуют обязательные поля в Initial-Dossier
HS_ERR_INSUFFICIENT_STAKE402Залоговый депозит ниже минимального порога
HS_ERR_DAT_REVOKED403DAT-A Лицензиара недействителен или отозван
HS_ERR_SIG_INVALID400Ошибка верификации подписи
CGW_ERR_AML_SCORE_EXCEEDED403Риск-скоринг выше допустимого порога
CGW_ERR_TRL_BLACKLISTED403Агент или кошелёк в TRL
CGW_ERR_JURISDICTION_LOCK403Оператор в запрещённой юрисдикции
CGW_ERR_SETTLEMENT_MISMATCH400Данные settlement_context не совпадают с транзакцией

7.2. Формат ответа ошибки

{
  "status": "error",
  "error": { "code": "PDT_ERR_TX_NOT_FOUND", "message": "Транзакция не подтверждена." },
  "retry_after_ms": 5000,
  "settlement_options": { "supported_methods": ["on-chain-direct"] }
}

Архитектурные изменения версии 1.1 (Резюме)

Резюме архитектурного перехода: От Коллегиального консенсуса к Делегированному доверию (sig.a)

В ходе плановой модернизации стандарта SOLPDT до версии 1.1 было принято стратегическое решение об оптимизации структуры доверия.

Ключевые изменения:

  • Упразднение коллегиальной подписи: Поле sig.n полностью удалено.
  • Централизация аттестации в sig.a: Подпись генерируется Уполномоченным Лицензиаром (DAT-A).
  • Валидация через статус DAT: Проверка цепочки [Агент: sig.a] → [Лицензиар: DAT] → [Root: Active Status].

Преимущества для экосистемы: Производительность, масштабируемость, юридическая чистота.

СТАТУС: Утверждено. Поле sig.n считается устаревшим (deprecated).

Приложения

Полный список приложений к спецификации SOLPDT 1.1 доступен по следующим ссылкам:

Буква Приложение Ссылка Описание
A Примеры транзакций Payload-V2 /appendix-a-v1-1 Базовый, с прямым платежом и расширенный для НМА
B Нормативные и связанные документы /appendix-b-v1-1 Перечень законодательных, технических и блокчейн-стандартов
C Схема Initial-Dossier (Handshake) /appendix-c-v1-1 JSON-схема и протокол получения sig.a
D Бухгалтерский контекст актива /appendix-d-v1-1 Параметры для учёта НМА (ФСБУ 14/2022, IAS 38)
E Справочник по амортизации /appendix-e-v1-1 Мультиплатформенная реализация расчёта амортизации
F Протокол списания /appendix-f-v1-1 Процедура списания НМА при срабатывании TRL
G Чек-лист аудитора /appendix-g-v1-1 Инструмент для внутреннего и внешнего аудита
H Шаблон акта списания НМА /appendix-h-v1-1 Первичный документ для бухгалтерского учёта
I Глоссарий Agentic Trust Layer /appendix-i-v1-1 Терминология для понимания стандарта
J Акт верификации НМА /appendix-j-v1-1 Шаблон первичного документа для постановки на баланс
K Методология признания НМА /appendix-k-v1-1 Методология признания ИИ-агентов в качестве НМА
L Акт совместимости с ERC-8004 и Google A2A /appendix-l-v1-1 Подтверждение технической совместимости
M Чек-лист для партнёров (RFC) /appendix-m-v1-1 8 пунктов проверки для технического ревью
N Пользовательские сценарии /appendix-n-v1-1 Практические примеры использования стандарта
O Иерархия ролей и типы DAT /appendix-o-v1-1 Четырехуровневая иерархия, DAT-H, DAT-M, DAT-A
P Гибридная архитектура реестров и ZKP /appendix-p-v1-1 Solana State Compression + локальный реестр, Groth16, Light Protocol
Примечание: Все приложения являются неотъемлемой частью спецификации SOLPDT 1.1. Актуальные версии документов доступны по указанным ссылкам.