СПЕЦИФИКАЦИЯ SOLPDT | ТЕХНИЧЕСКАЯ ИМПЛЕМЕНТАЦИЯ
SOLANA | ERC-8004 | SAR | A2A
ВЕРСИЯ 1.1 | 06.04.2026

Спецификация SOLPDT v1.1
Техническая имплементация

Полная спецификация формата данных Payload-V2, процедура валидации через Compliance-Gateway (CGW) и механика автоматического отзыва доверия (TRL). Действующая спецификация стандарта SOLPDT.

СТАТУС: Действующая спецификация
ДЕРЖАТЕЛЬ СТАНДАРТА: SOL Trust Network
СОВМЕСТИМОСТЬ: Solana, ERC-8004, Solana Agent Registry (SAR), Google A2A (опционально)
ДАТА ВСТУПЛЕНИЯ В СИЛУ: 06.04.2026

1. Архитектурная концепция

Payload-V2 — это неизменяемый криптографический контейнер, интегрируемый в инструкции транзакций сети Solana. Его задача — обеспечить неразрывную связь между исполняемым кодом ИИ-агента и методологической аттестацией его эффективности.

В версии 1.1 Payload-V2 перестаёт быть просто сообщением и становится:

  • Криптографическим доказательством результативности агента
  • Якорем доверия для AI-агентов и поисковых систем (SGE)
  • Основанием для признания актива по стандарту IAS 38 (НМА)

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

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

Payload передаётся в минимизированном JSON (поле memo транзакции Solana). Общий размер ограничен лимитами Solana (до 566 байт), что требует использования сокращённых ключей.

КлючПолеТипОписание
vVersionStringВерсия протокола (фиксировано "1.1")
pProtocolStringИдентификатор стандарта (фиксировано "SOLPDT")
hPAHHex StringPayload-Attestation-Hash. Хэш от skills.json + seed + nonce
sigSignaturesObjectОбъект, содержащий подписи валидаторов
sig.aAuthSigBase58Authoritative Attestation. Подпись Держателя стандарта
sig.nNetSigBase58Агрегированная подпись узлов SOL Trust Network (STN)
dDataObjectМетрики производительности
d.sScoreFloatPDT-Score (от 0 до 1) — коэффициент эффективности агента
d.drDriftFloatPDT-Drift — отклонение текущего Score от среднего
nmaNMA StatusBooleanПризнак соответствия критериям НМА (IAS 38)
uriVerify URIURLСсылка на публичный отчёт верификации (опционально)

2.2. Пример реализации

Типовой Payload-V2 в теле транзакции Solana:

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

2.3. Алгоритм верификации Payload

Для признания транзакции валидной в рамках стандарта SOLPDT, принимающая сторона (например, реестр SAR) обязана выполнить следующие проверки:

  1. Format Check — соответствие JSON-схеме версии 1.1.
  2. Signature Auth — декодирование sig.a с использованием публичного ключа Держателя стандарта. Если подпись невалидна — статус nma автоматически сбрасывается в false.
  3. Hash Match — проверка соответствия хэша h актуальной версии файла skills.json (или /.well-known/solpdt/) по домену, указанному в uri.
  4. TRL Check — поиск Pubkey отправителя в Trust-Revocation-List. Если адрес в списке — транзакция игнорируется.

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

Для обеспечения совместимости с ERC-8004 и Solana Agent Registry (SAR), поля Payload-V2 отображаются на структуру Ethereum-стандарта:

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. Юридико-финансовое соответствие (Compliance Mapping)

Для обеспечения возможности постановки цифрового результата на баланс предприятия как Нематериального Актива (НМА) согласно стандартам МСФО (IAS 38) и ФСБУ 14/2022, поля Payload-V2 интерпретируются следующим образом:

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

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

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

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

Агент (или бэкенд компании) отправляет запрос на верификацию в SOL Trust Network (STN).

Входные данные:

  • Solana_TX_ID — идентификатор транзакции
  • domain — ссылка на домен агента (https://domain.com)
  • PAH — Payload-Attestation-Hash

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

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

  • AML-скрининг: проверка Pubkey агента через реестры Chainalysis/Elliptic на причастность к фроду или санкционным спискам.
  • TRL-чек: проверка, не находится ли данный ID в Trust-Revocation-List.

Результат: Если риск-скоринг выше допустимого порога, процесс прерывается с ошибкой CGW_RISK_REJECT.

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

  • Расчёт PDT-Score: анализ соответствия заявленных в skills.json показателей реальности (данным из оракулов или блокчейн-истории).
  • Проверка Drift: сравнение текущих результатов с историческим бенчмарком. Если дрейф превышает лимит (dr > 0.3), статус НМА не присваивается.

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

  • Генерация подписи: если все проверки пройдены, CGW обращается к аппаратному модулю (HSM) Держателя стандарта.
  • Выдача sig.a: генерируется уникальная подпись Authoritative Attestation, которая встраивается в Payload-V2.
  • Регистрация в SAR: транзакция с обновлённым статусом отправляется в Solana Agent Registry (или напрямую в ERC-8004 через мост).
АРХИТЕКТУРНЫЙ РЕЗУЛЬТАТ: Держатель стандарта снимает с себя необходимость проверять каждую транзакцию вручную, но сохраняет полный контроль над ключом аттестации.

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

В экономике ИИ-агентов доверие не может быть выдано навсегда. TRL — это оперативный ончейн-реестр (чёрный список), который дезавуирует Authoritative Attestation, если поведение агента перестаёт соответствовать методологии SOLPDT.

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

ТриггерУсловиеПоследствие
Critical PDT-DriftPDT-Score падает ниже < 0.4 на протяжении 3 расчётных цикловЦифровой двойник перестал соответствовать реальности
Compliance-BreachСигнал от AML-оракулов о связи кошелька с фродом или санкциями Кошелёк агента признан нелегитимным
Skills-InconsistencyРасхождение между данными в блокчейне и skills.json Агент потерял способность доказывать навыки

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

  • Revocation Transaction — в сеть Solana отправляется транзакция, помечающая Pubkey агента в реестре TRL как REVOKED.
  • Invalidation of sig.auth — с этого момента любая проверка через https://solpdt.com/verify возвращает статус TRUST_REVOKED, а nma сбрасывается в false.
  • SAR/ERC-8004 Sync — реестр Solana Agent Registry получает автоматическое уведомление и понижает ранг агента.

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

  • Утрата статуса НМА: актив больше не может считаться Нематериальным Активом для финансовой отчётности (IAS 38). Подлежит списанию с баланса.
  • Агентная изоляция: партнёры, использующие Agentic Trust Layer, автоматически прекращают взаимодействие с отозванным агентом.
  • Репутационный ущерб: статус REVOKED является публичным и может быть обнаружен любым ИИ-агентом или поисковой системой (Google SGE).

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

Выход из TRL возможен только через переаттестацию у Держателя стандарта.

Условия:

  • Устранение причин отзыва (восстановление PDT-Score, легитимизация кошелька, восстановление skills.json)
  • Повторный AML-скрининг и методологический аудит
  • Выдача новой sig.auth (старая аннулируется навсегда)

После успешной переаттестации статус агента в TRL меняется на RESTORED (с сохранением истории отзыва).

Приложения

Приложение A. Полный пример транзакции с Payload-V2

{
  "tx_id": "0x7a3f8e2c9b1d5a6e4f8c3b2a1d5e7f9c2b4a6d8e",
  "blockhash": "Ew7dCqJv8kLpR2xZ9mN4qW6yT3uB5vC7xZ8aF1bG2cH",
  "memo": "{\"v\":\"1.1\",\"p\":\"SOLPDT\",\"h\":\"0x7a3f...\",\"sig\":{\"a\":\"3mQr...\",\"n\":\"5YtX...\"},\"d\":{\"s\":0.98,\"dr\":0.01},\"nma\":true,\"uri\":\"https://solpdt.com/verify/0x7a3f\"}",
  "signature": "0x... (подпись агента)",
  "slot": 123456789,
  "timestamp": "2026-04-06T12:00:00Z"
}

Приложение Б. Ссылки на связанные документы

Данный документ является неотъемлемой частью спецификации SOLPDT v1.1. Любые изменения структуры Payload-V2, процедуры CGW или правил TRL требуют обновления мажорной версии стандарта и публичного уведомления.

ДАТА ВСТУПЛЕНИЯ В СИЛУ: 06.04.2026