SOLPDT 1.1 | APPENDIX M
PARTNER TECHNICAL REVIEW CHECKLIST
RFC | REQUEST FOR COMMENTS

Приложение M: Чек-лист для партнёров
Partner Technical Review Checklist

Стандарт: SOLPDT 1.1 — Agentic Trust Layer Extension
Статус: RFC (Request for Comments)

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

Настоящее приложение содержит чек-лист технического ревью для партнёров экосистемы SOLPDT, планирующих интеграцию со стандартом SOLPDT 1.1. Документ предназначен для:

  • Технологических партнёров (Интеграторов) — Quantu AI, Helius, провайдеры RPC-узлов
  • Лицензиаров — региональных узлов SOL Trust Network, разворачивающих Compliance-Gateway
  • Разработчиков ИИ-агентов — команд, создающих агентов, совместимых с SOLPDT
  • Инфраструктурных провайдеров — операторов SAR, SATI, ERC-8004-совместимых реестров

Цель: Оценить совместимость предложенных в спецификации SOLPDT 1.1 решений с текущей инфраструктурой партнёра, выявить потенциальные риски и сформировать план адаптации.

Заполненный чек-лист рекомендуется направить на standards@solpdt.com для учёта в процессе развития стандарта.

M.2. Информация о партнёре

ПараметрЗначение
Наименование организации[Partner.Name]
Тип партнёрства☐ Технологический партнёр (Интегратор) ☐ Лицензиар ☐ Разработчик агента ☐ Инфраструктурный провайдер
Контактное лицо[Contact.Name]
Email[Contact.Email]
Дата заполнения[Date]
Версия чек-листа1.0

M.3. Чек-лист технического ревью

Пожалуйста, оцените каждый пункт и отметьте соответствующий статус. При наличии рисков или замечаний заполните колонку «Комментарий».

Пункт проверкиСтатусКомментарий
1 Структура Payload-V2
Является ли формат JSON-объекта (включая поля v, p, h, sig, d, nma, uri, settlement_context) совместимым с вашими методами сжатия и парсинга (SAR / Photon / ZK)?
Ограничение размера: 566 байт в поле memo транзакции Solana.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
2 Settlement Layer
Поддерживает ли ваш шлюз / нода валидацию settlement_context (извлечение tx_id и сверку суммы в USDC или ином токене) без значительных задержек?
Требуется доступ к RPC Solana с историей транзакций.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
3 Идемпотентность (TTL 48 часов)
Позволяет ли ваша архитектура БД / кэша хранить связку Payload_Hash + tx_id в течение 48 часов для исключения дублирующих вызовов RPC?
Требуется поддержка TTL и атомарной записи.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
4 Latency (целевой показатель)
Считаете ли вы достижимым время отклика Gateway (от запроса до выдачи sig.a) в пределах 500 мс для 95% запросов при использовании кэширования?
Без учёта времени подтверждения транзакции в Solana.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
5 Обработка ошибок
Является ли предложенная сетка HTTP-статусов (400, 402, 403, 404, 429, 503) и кодов PDT_ERR_... достаточной для корректной автоматизации действий ваших агентов?
См. раздел 7 основной спецификации.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
6 Поля обратной связи
Достаточно ли массива supported_methods и заголовка X-Cache-TTL-Remaining для управления логикой Fallback (переключения методов оплаты с subscription на on-chain-direct)?
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
7 Расширяемость (готовность к v1.2 / x402)
Видите ли вы технические препятствия для добавления новых ключей в settlement_context (например, под протокол x402) без нарушения логики парсинга текущей версии?
Спецификация требует, чтобы неизвестные ключи игнорировались.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]
8 Безопасность (Time-Window)
Считаете ли вы окно в 48 часов для валидации транзакций в Solana оптимальным балансом между защитой от Replay-атак и пользовательским опытом?
Транзакции старше 48 часов не принимаются.
☐ OK
☐ Есть риск
☐ Требуется доработка
[Comment]

M.4. Дополнительные вопросы (опционально)

ВопросОтвет / Комментарий
9 Поддержка Token-2022
Поддерживает ли ваша инфраструктура Token Extensions (Transfer Hook, Permanent Delegate), необходимые для работы Compliance-Gateway и механизма слэшинга?
[Answer]
10 ZK-компрессия
Используете ли вы ZK Compression (Light Protocol / Helius) для хранения данных TRL? Если да, совместим ли ваш формат с предложенной схемой?
[Answer]
11 Интеграция с SAR
Планируете ли вы регистрацию в Solana Agent Registry (SAR) в качестве верификатора для профиля SOLPDT_v1?
[Answer]
12 Дополнительные требования
Есть ли у вас специфические требования к формату данных или протоколам взаимодействия, не учтённые в текущей спецификации SOLPDT 1.1?
[Answer]

M.5. Сводная оценка совместимости

ПараметрЗначение
Общая оценка совместимости ☐ Полная совместимость
☐ Частичная совместимость (требуются доработки)
☐ Не совместимо
Критические блокеры[List of blockers]
Рекомендуемый срок адаптации[Estimated time]
Необходимая поддержка от SOL Trust Network[Support requests]

M.6. План действий по результатам ревью

Выявленная проблемаПредлагаемое решениеОтветственныйСрок
1[Issue][Solution][Owner][Date]
2[Issue][Solution][Owner][Date]
3[Issue][Solution][Owner][Date]

M.7. Контактная информация SOL Trust Network

Для направления заполненного чек-листа, а также для получения консультаций по техническим вопросам интеграции:

КаналЗначение
Emailstandards@solpdt.com
Telegram@solpdt_support
GitHub (Mos.Hub)https://mos.hub/solpdt
Веб-сайтhttps://solpdt.com

M.8. История изменений чек-листа

ВерсияДатаИзменения
1.008.04.2026Первоначальная версия для SOLPDT 1.1 RFC

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

ДокументСсылка
Основная спецификация SOLPDT 1.1/specification-v1-1
Приложение C: Initial-Dossier Schema/appendix-c-v1-1
Приложение D: Бухгалтерский контекст/appendix-d-v1-1
Приложение F: Протокол списания/appendix-f-v1-1
Скачать PDF-версию чек-листа/appendix-m-v1-1/checklist.pdf

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