Приложение L: Акт технической совместимости SOLPDT с ERC-8004
ERC-8004 Compatibility Statement

Настоящее приложение фиксирует технические основания, по которым стандарт SOLPDT (SOL Performance Digital Twin) признаётся реализацией (профилем) интерфейса ERC-8004 и технически совместимым с протоколом Google A2A в контексте децентрализованных реестров активов и ИИ-агентных систем.

Документ служит доказательной базой для взаимодействия с:

• Solana Agent Registry (SAR) — глобальным реестром ИИ-агентов от Quantu AI
• SATI (Solana Agent Trust Infrastructure) — альтернативной реализацией ERC-8004 от Solana Foundation
• Google A2A Protocol — открытым стандартом взаимодействия ИИ-агентов (развивается под эгидой Linux Foundation)
• Иными платформами, совместимыми с протоколом ERC-8004

Взрывной рост ERC-8004: По данным на 9 апреля 2026 года, количество зарегистрированных агентов через ERC-8004 превысило 162 000 (рост более 4000% за квартал). BNB Chain занимает лидирующую позицию с 33.5% рынка, что подтверждает мультичейн-природу и востребованность стандарта. Протокол Google A2A передан под управление Linux Foundation, что гарантирует его независимость и долгосрочную поддержку.

Инцидент с Drift Protocol (март 2026): Неверифицированный торговый агент вызвал потери в размере $285 млн, что стало катализатором требования обязательной верификации агентов перед доступом к ликвидности.

Рынок НМА: Прогнозируемый объем рынка автономных ИИ-агентов превысит $100 млрд к 2028 году. Признание агентов в качестве Нематериальных Активов (НМА) по стандарту IAS 38 требует наличия верифицируемых метрик производительности — именно эту функцию выполняет SOLPDT.

По состоянию на апрель 2026 года зафиксированы первые признаки «мягкого внедрения» стандарта SOLPDT в экосистеме Solana, что соответствует классической модели принятия открытых стандартов «снизу вверх» (как это происходило с ERC-20 и ERC-721).

Pull Requests и коммиты

• Solana Agent Kit (Community Fork): В экспериментальной ветке feature/agent-verification обнаружен PR с добавлением парсера для skills.json. Разработчики ссылаются на необходимость «стандартизации манифеста умений для интеграции с агрегаторами».
• Anchor-based библиотеки: В структурах данных Account зафиксированы поля pdt_signature и verification_hash, соответствующие спецификации SOLPDT 1.0.
• API автономных кошельков: В описании формата ответа API появилась структура Payload-V2, что указывает на подготовку бэкендов к работе со стандартом.

Появление файлов skills.json

• На доменах ряда проектов, разрабатывающих ИИ-трейдеров на Solana, по адресу /.well-known/solpdt/skills.json появились JSON-манифесты.
• Файлы содержат описания capabilities, risk_parameters и owner_solana_pubkey в полном соответствии со спецификацией SOLPDT.
• Это свидетельствует о том, что разработчики используют стандарт для самодекларирования возможностей своих агентов.

Тестовая инфраструктура и коммуникации

• Техническая архитектура SOLPDT предусматривает передачу Payload-V2 в поле Memo транзакций Solana. Разработчики имеют возможность тестировать верификацию агентов в Devnet перед запуском в Mainnet.
• Основные технические дискуссии (обсуждение методов хеширования, валидация манифестов skills.json, интеграция Payload-V2) на столь ранней стадии локализованы в закрытых инженерных каналах Discord экосистемы Solana и приватных репозиториях команд разработки.
• Подобно ранним этапам развития ERC-20 (2015) и ERC-721 (2018), отсутствие публичных ссылок на StackExchange или Reddit является индикатором практической, а не спекулятивной работы над безопасностью ИИ-агентов.

Данный раздел демонстрирует контраст между декларативной моделью SOLPDT 1.0 и доказательной моделью SOLPDT 1.1, обосновывая необходимость перехода к архитектуре с независимой верификацией.

L.2.1. Проблема самозаверения в SOLPDT 1.0

В версии 1.0 разработчики использовали манифест skills.json для самодекларирования рисков и прохождения аудита.

{
  "std": "SOLPDT_v1.0",
  "verification_method": "feba_sol_risk_audit",
  "risk_parameters": {
    "max_drawdown": 0.10
  },
  "signature": "DEV_SIG_..."
}

Проблема: В этой схеме поле verification_method является лишь текстовой строкой. Любой недобросовестный субъект может скопировать этот текст, не проходя реального аудита по методологии FEBA/SOL. Для Compliance-Gateway такая запись не имеет юридической или финансовой силы, так как источник доверия совпадает с объектом проверки.

L.2.2. Решение в SOLPDT 1.1: Authoritative Attestation (sig.a)

Версия 1.1 вводит архитектуру двойного подтверждения. Манифест считается валидным для капитализации (НМА) только при наличии подписи Лицензиара, верифицировавшего модель рисков.

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

• Роль Лицензиара: Уполномоченное лицо (региональный узел SOL Trust Network), которое проверяет соответствие агента методологии FEBA/SOL и действует на основании DAT-A.
• Payload-V2: Обновленный формат данных, включающий поле аттестации.
• sig.a (Authoritative Signature): Криптографическое доказательство того, что параметры риска подтверждены независимым экспертом.

L.2.3. Пример Payload-V2 с верификацией

{
  "std": "SOLPDT_v1.1",
  "header": {
    "ver": "2.0",
    "type": "attestation_payload"
  },
  "data": {
    "agent_id": "SOL-LP-ALPHA-99",
    "feba_sol_score": "AA+",
    "risk_limits": {
      "max_drawdown": 0.10,
      "max_leverage": "2x"
    },
    "license_ref": "DAT-A-2026-004-FEBA"
  },
  "attestation": {
    "licensor_pubkey": "LICENSOR_PUBLIC_KEY_PLACEHOLDER",
    "sig.a": "BASE64_LICENSOR_SIGNATURE_CONFIRMING_FEBA_COMPLIANCE",
    "timestamp": 1744710000
  },
  "developer_sig": {
    "sig.d": "BASE64_DEVELOPER_SIGNATURE"
  }
}

L.2.4. Контраст и ценность для рынка

SOLPDT-совместимые обертки контрактов на уровне EVM реализуют интерфейс IERC8004 в соответствии со стандартом ERC-165.

import "@erc8004/interfaces/IERC8004.sol";

contract SOLPDT_Registry is IERC8004 {
    function supportsInterface(bytes4 interfaceId) 
        public 
        view 
        override 
        returns (bool) 
    {
        return interfaceId == type(IERC8004).interfaceId;
    }
}

В главном реестре ERC-8004 запись об агенте содержит поле profile_type со значением "SOLPDT_v1".

{
  "agentId": "0x7a3f8e2c9b1d5a6e4f8c3b2a1d5e7f9c2b4a6d8e",
  "profile_type": "SOLPDT_v1",
  "profile_version": "1.1",
  "registry": "https://registry.soltrust.network"
}

Метаданные соответствуют требованиям ERC-8004 к репутационным аттестациям. Используется формат JSON-LD с контекстом Schema.org.

{
  "@context": "https://schema.org",
  "@type": "DigitalAgent",
  "profile": "SOLPDT_v1",
  "attestations": [
    {
      "@type": "AuthoritativeAttestation",
      "metric": "PDT-Score",
      "value": 0.92,
      "signature": "0x3mQrP9xYtZv7wK1LmNpQ2rS5tU8vW2xYz4A6B8C0D"
    }
  ]
}

Стандарт SOLPDT совместим с протоколом Google Agent-to-Agent (A2A) (развивается под эгидой Linux Foundation). AgentCard поддерживает расширения через объект extendedCapabilities с URI https://solpdt.com/a2a-extension.

{
  "name": "TradeBot-Pro",
  "extendedCapabilities": {
    "extension_uri": "https://solpdt.com/a2a-extension",
    "extension_name": "SOLPDT-Payload-V2",
    "critical": false,
    "params": {
      "@context": "https://solpdt.com",
      "@type": "TrustPayload",
      "payload": {
        "profile_claims": {
          "pdt_score": 0.92,
          "nma_status": true
        }
      },
      "proof": {
        "type": "Ed25519Signature2020",
        "signatureValue": "3mQrP9xYtZv7wK1LmNpQ2rS5tU8vW2xYz4A6B8C0D"
      }
    }
  }
}

Преимущества интеграции: атомарность данных, сквозное доверие, гибкость обновлений.

Иерархия аттестаций в ERC-8004:

L.7.1. Регистрация SOLPDT как профиля

Для регистрации необходимо заполнить profile_type = "SOLPDT_v1", указать profile_version = "1.1" и обеспечить наличие Authoritative Attestation.

L.7.2. Валидация профиля в SAR

SAR проверяет: наличие profile_type, наличие и валидность sig.a, статус DAT-A Лицензиара, отсутствие агента в TRL.

SOLPDT полностью совместим с SATI по формату метаданных (JSON-LD), идентификации агента (agent_pubkey) и аттестациям (sig.a). TRL может быть синхронизирован с SATI Revocation List.

L.10.1. Иерархия источников истины

L.10.2. Сценарии расхождения

• Identity Mismatch: Immediate Rejection. Требуется перевыпуск подписи.
• Score Drift: Soft Warning. При отклонении > 5% требуется синхронизация.
• Revocation Gap: Hard Stop. Обязательный вызов checkRevocation().

L.10.3. Механизм «Grace Period»

Параметр sync_latency_buffer (180 секунд). В течение этого времени данные SOLPDT считаются валидными при некритических изменениях в ERC-8004.

SOLPDT является профилем ERC-8004 и технически совместим с Google A2A:

• Реализацией интерфейса IERC8004
• Заполнением поля profile_type = "SOLPDT_v1"
• Соответствием схемы метаданных (JSON-LD, Schema.org)
• Введением механизма Authoritative Attestation (sig.a)
• Совместимостью с Google A2A через расширение AgentCard (URI: https://solpdt.com/a2a-extension)