SOLPDT 1.1 | APPENDIX C
HANDSHAKE PROTOCOL | INITIAL-DOSSIER SCHEMA
VERSION 1.1 | 09.04.2026

Appendix C: Initial-Dossier Schema

SOLPDT 1.1 — Agentic Trust Layer Extension

C.1. Назначение

Настоящее приложение определяет процедуру Handshake (рукопожатия) — строго регламентированный процесс, в ходе которого Агент доказывает свою техническую и юридическую состоятельность Лицензиару для получения аттестата sig.a (Authoritative Attestation).

Initial-Dossier — это структурированный JSON-документ, который Агент передаёт Лицензиару при инициации процедуры верификации. Документ содержит все необходимые данные для проведения автоматизированного аудита в соответствии с методологией SOLPDT.

После успешного прохождения Handshake Лицензиар выдаёт цифровую подпись sig.a, которая встраивается в поле sig.a структуры Payload-V2 (см. раздел 2.1 основной спецификации). Без валидной sig.a транзакции Агента не признаются доверенными в экосистеме SOLPDT, а статус nma не может быть установлен в true.

C.2. Процедура Handshake (пошаговая схема)

Шаг 1. Инициация (Request for Attestation)

Агент формирует Initial-Dossier в формате JSON согласно схеме, приведённой в разделе C.3, и отправляет его Лицензиару через API или защищённый канал связи. Запрос должен содержать уникальный request_id и криптографический nonce для защиты от повторного использования.

Шаг 2. Техническая проверка (Automated Validation)

Лицензиар проводит автоматизированный аудит Агента, включающий:

  • Проверку соответствия кода Агента стандарту Payload-V2
  • Валидацию Compliance-Gateway Program ID в сети Solana
  • Тестовый запрос к RPC-эндпоинту Агента
  • Проверку наличия и суммы залогового депозита на stake_account

Шаг 3. Проверка полномочий (DAT Verification)

Агент проверяет Digital Access Token (DAT) Лицензиара, используя ссылку licensor_dat_ref из собственного досье. Проверка включает:

  • Валидность подписи DAT (выдан Корневым узлом)
  • Отсутствие DAT в реестре отозванного доверия (TRL)

Если DAT валиден, доверие между Агентом и Лицензиаром считается установленным.

Шаг 4. Генерация аттестата (Issuance of sig.a)

После успешного прохождения всех проверок Лицензиар:

  • Подписывает структуру данных Агента своим закрытым ключом Ed25519, привязанным к DAT
  • Создаёт уникальную подпись sig.a (Authoritative Attestation)
  • Отправляет sig.a на callback_url, указанный в Initial-Dossier
  • Вносит запись об аттестации в распределённый реестр доверия

Шаг 5. Активация Payload-V2

С этого момента Агент включает полученную sig.a в поле sig.a каждой транзакции Payload-V2. Любой участник экосистемы SOLPDT может мгновенно проверить подпись и убедиться, что Агент верифицирован аккредитованным Лицензиаром.

Диаграмма состояний Handshake

┌─────────────────┐ │ DRAFT │ Агент формирует Initial-Dossier └────────┬────────┘ ▼ ┌─────────────────┐ │ SUBMITTED │ Досье отправлено Лицензиару └────────┬────────┘ ▼ ┌─────────────────┐ │ VALIDATING │ Проверка полей, залога, CGW, DAT └────────┬────────┘ ├──────────────────┐ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ APPROVED │ │ REJECTED │ │ (выдана sig.a)│ │ (требует │ └────────┬────────┘ │ исправления) │ │ └─────────────────┘ ▼ ┌─────────────────┐ │ ACTIVE │ sig.a активна, транзакции доверенные └────────┬────────┘ │ (при нарушении) ▼ ┌─────────────────┐ │ REVOKED │ sig.a отозвана через TRL └─────────────────┘

C.3. JSON-схема Initial-Dossier

Ниже представлена эталонная структура Initial-Dossier. Все поля, отмеченные как required, обязательны к заполнению. Отсутствие любого обязательного поля приводит к отклонению запроса с кодом HS_ERR_MISSING_FIELDS.

{
  "dossier_header": {
    "version": "1.1",
    "request_id": "req-987456321",
    "timestamp": 1715856000,
    "nonce": "a7b8c9d0e1f2"
  },
  
  "identity_block": {
    "agent_pubkey": "A1b2C3d4E5f6G7h8I9j0K1l2M3n4O5p6Q7r8S9t0U1v",
    "operator_id": "LLC-TECH-AGENT-01",
    "legal_jurisdiction": "RU",
    "controller_sig": "3z9x8c7v6b5n4m3l2k1j0h9g8f7e6d5c4b3a2"
  },
  
  "technical_manifest": {
    "payload_standard": "Payload-V2",
    "crypto_suite": "AES-GCM-256-Ed25519",
    "compliance_gateway_program_id": "CGW1111111111111111111111111111111111111",
    "rpc_endpoint_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  },
  
  "security_trust_layer": {
    "stake_account": "Stake99999999999999999999999999999999999999",
    "min_stake_amount": 50.0,
    "staking_token": "SOL",
    "slashing_consent": true,
    "trl_monitoring_enabled": true
  },
  
  "accounting_context": {
    "ias_38_compliance": true,
    "fsbu_14_2022_support": true,
    "asset_type": "Digital_Intangible_Asset",
    "valuation_oracle": "Pyth-Network-Mainnet",
    "base_currency": "RUB"
  },
  
  "attestation_meta": {
    "licensor_dat_ref": "DAT-888-REGIONAL-NODE-05",
    "callback_url": "https://agent-api.internal/solpdt/callback"
  }
}

C.4. Описание полей

C.4.1. Блок dossier_header

ПолеТипОбязательностьОписание
versionStringrequiredВерсия протокола SOLPDT. Фиксированное значение "1.1".
request_idStringrequiredУникальный идентификатор запроса. Рекомендуется формат req-{unix_timestamp}-{random}.
timestampIntegerrequiredUnix-время (секунды) формирования запроса.
nonceStringrequiredКриптографическая соль. Минимум 12 символов. Защита от replay-атак.

C.4.2. Блок identity_block

ПолеТипОбязательностьОписание
agent_pubkeyStringrequiredПубличный ключ Агента в сети Solana (Base58).
operator_idStringrequiredИдентификатор юридического лица или оператора Агента.
legal_jurisdictionStringrequiredКод юрисдикции по стандарту ISO 3166-1 alpha-2 (например, RU, US, DE).
controller_sigStringrequiredПодпись владельца приватного ключа, подтверждающая контроль над agent_pubkey.

C.4.3. Блок technical_manifest

ПолеТипОбязательностьОписание
payload_standardStringrequiredФиксированное значение "Payload-V2".
crypto_suiteStringrequiredИспользуемый набор криптографических алгоритмов. Допустимые значения: AES-GCM-256-Ed25519.
compliance_gateway_program_idStringrequiredProgram ID смарт-контракта Compliance-Gateway в сети Solana (Base58).
rpc_endpoint_hashStringrequiredSHA-256 хеш URL доверенного RPC-узла, через который Агент взаимодействует с сетью.

C.4.4. Блок security_trust_layer

ПолеТипОбязательностьОписание
stake_accountStringrequiredАдрес аккаунта в Solana, на котором заблокирован гарантийный депозит (Stake).
min_stake_amountFloatrequiredМинимальная сумма залога в токенах, указанных в staking_token.
staking_tokenStringrequiredТикер токена залога (SOL, USDC, или другой SPL-токен).
slashing_consentBooleanrequiredПодтверждение согласия с условиями изъятия залога при нарушении. Должен быть строго true.
trl_monitoring_enabledBooleanrequiredПодтверждение готовности к мониторингу через TRL. Должен быть строго true.

C.4.5. Блок accounting_context

ПолеТипОбязательностьОписание
ias_38_complianceBooleanrequiredПодтверждение соответствия стандарту IAS 38 (МСФО).
fsbu_14_2022_supportBooleanrequiredПодтверждение соответствия стандарту ФСБУ 14/2022 (РФ).
asset_typeStringrequiredТип нематериального актива. Рекомендуемое значение: Digital_Intangible_Asset.
valuation_oracleStringrequiredИдентификатор оракула цены (например, Pyth-Network-Mainnet).
base_currencyStringrequiredВалюта учёта по ISO 4217 (RUB, USD, EUR).

C.4.6. Блок attestation_meta

ПолеТипОбязательностьОписание
licensor_dat_refStringrequiredИдентификатор Digital Access Token (DAT) Лицензиара, выданного Корневым узлом.
callback_urlStringrequiredURL для получения sig.a после успешной аттестации. Должен принимать POST-запросы.

C.5. Валидационные правила

ПолеПравило валидацииДействие при ошибке
slashing_consentДолжен быть строго true.Отказ с кодом HS_ERR_SLASHING_CONSENT_FALSE. Агент не принимает экономическую ответственность.
trl_monitoring_enabledДолжен быть строго true.Отказ с кодом HS_ERR_TRL_MONITORING_DISABLED.
stake_accountДолжен содержать залог ≥ min_stake_amount в токене staking_token.Отказ с кодом HS_ERR_INSUFFICIENT_STAKE.
compliance_gateway_program_idДолжен быть валидным Program ID в сети Solana.Отказ с кодом HS_ERR_INVALID_CGW.
licensor_dat_refDAT должен быть выдан Корневым узлом и не находиться в TRL.Отказ с кодом HS_ERR_DAT_REVOKED.
callback_urlДолжен быть доступен и возвращать HTTP 200 на тестовый POST-запрос.Отказ с кодом HS_ERR_CALLBACK_UNREACHABLE.
legal_jurisdictionДолжен соответствовать ISO 3166-1 alpha-2.Отказ с кодом HS_ERR_INVALID_JURISDICTION.

C.6. Интеграция с Payload-V2

После успешного Handshake, полученная sig.a встраивается в поле sig.a структуры Payload-V2 (см. раздел 2.1 основной спецификации).

Связь полей Initial-Dossier и Payload-V2

Initial-DossierPayload-V2Назначение
agent_pubkeyОтправитель транзакцииИдентификация Агента в сети Solana
compliance_gateway_program_idTransfer Hook токенаAML-проверка при каждой транзакции
stake_accountРезерв для слэшингаИсточник средств при экономическом наказании
valuation_oraclesettlement_context.currency (косвенно)Оценка стоимости актива
base_currencysettlement_context.currencyВалюта расчётов

C.7. Коды ошибок Handshake

Код ошибкиHTTP статусОписаниеРекомендуемое действие
HS_ERR_MISSING_FIELDS400Отсутствуют обязательные поля в Initial-Dossier.Проверить схему JSON.
HS_ERR_SLASHING_CONSENT_FALSE403slashing_consent !== true.Установить true.
HS_ERR_TRL_MONITORING_DISABLED403trl_monitoring_enabled !== true.Установить true.
HS_ERR_INSUFFICIENT_STAKE402Залог на stake_account меньше min_stake_amount.Пополнить залоговый депозит.
HS_ERR_INVALID_CGW400compliance_gateway_program_id невалиден.Проверить Program ID.
HS_ERR_DAT_REVOKED403DAT Лицензиара отозван или в TRL.Обратиться к другому Лицензиару.
HS_ERR_CALLBACK_UNREACHABLE503callback_url недоступен.Проверить доступность эндпоинта.
HS_ERR_INVALID_JURISDICTION400Некорректный код юрисдикции.Использовать ISO 3166-1 alpha-2.
HS_ERR_DUPLICATE_REQUEST409request_id уже был использован.Сгенерировать новый request_id.
HS_ERR_TIMESTAMP_EXPIRED400timestamp отличается от серверного времени более чем на 300 секунд.Синхронизировать время.

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

{
  "status": "error",
  "error": {
    "code": "HS_ERR_INSUFFICIENT_STAKE",
    "message": "Залог на счёте Stake999... составляет 25.0 SOL, требуется минимум 50.0 SOL."
  },
  "request_id": "req-987456321",
  "retry_possible": true
}

C.8. Пример успешного ответа Лицензиара

При успешной верификации Лицензиар отправляет на callback_url следующий JSON:

{
  "status": "approved",
  "request_id": "req-987456321",
  "agent_pubkey": "A1b2C3d4E5f6G7h8I9j0K1l2M3n4O5p6Q7r8S9t0U1v",
  "sig_a": "5YtXz2M4pQ7rS9tU1vW3xY5zA7bC9dE1fG3hJ5kL7mN9pQ2rS5tU8vW2xYz4A6B8C0D",
  "licensor_dat_ref": "DAT-888-REGIONAL-NODE-05",
  "issued_at": 1715856300,
  "valid_until": 1747392300,
  "attestation_uri": "https://solpdt.com/verify/sig/5YtXz2M4pQ7..."
}

Агент обязан сохранить sig.a и включать её в каждую транзакцию Payload-V2. Срок действия аттестата (valid_until) составляет 365 дней с момента выдачи, после чего требуется повторное прохождение Handshake.

C.9. Требования безопасности

  • Защита от replay-атак: Каждый request_id может быть использован только один раз. Лицензиар обязан вести реестр обработанных request_id с TTL не менее 7 дней.
  • Валидация timestamp: Запросы с timestamp, отличающимся от серверного времени более чем на 300 секунд, должны отклоняться.
  • Проверка controller_sig: Подпись должна верифицироваться публичным ключом agent_pubkey. Используется алгоритм Ed25519.
  • Безопасность callback_url: Рекомендуется использовать HTTPS с валидным TLS-сертификатом. Лицензиар может требовать дополнительную аутентификацию (API key, mutual TLS).
  • Хранение sig.a: Агент должен хранить sig.a в защищённом хранилище (HSM, секреты Kubernetes, Vault). Компрометация sig.a эквивалентна компрометации аттестации.

КОРНЕВОЙ УЗЕЛ (СОЗДАТЕЛЬ СТАНДАРТА): Юрий Соколов (SOL Trust Network)
КОНТАКТЫ: standards@solpdt.com