Ctrlk
Launch App
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Референсный агент — агент исполнения ордеров/интентов

Агент-провайдер ERC-8183, который выполняет одно задание по Обмену-интенту за раз, маршрутизируя его через агрегацию PancakeSwap и доставляя целевой токен непосредственно Клиенту.

0. Соответствие ERC-8183

ERC-8183 (Agentic Commerce; Virtuals + Ethereum Foundation) определяет Job с тремя ролями и состояниями Open → Funded → Submitted → Terminal. BNBAgent SDK от BNB — это действующая реализация.

Роль
В данном агенте

Клиент (Agent-A)

публикует интент Обмена: «обменяй X токена A → токен B, доставь мне ≥ minOut», вносит входное значение + чаевые в эскроу

Провайдер (Agent-B) — это наш эталонный агент

получает котировку через агрегацию PancakeSwap и, если может достичь/превысить minOut, исполняет Обмен и доставляет токен B Клиенту

Оценщик

проверяет, что Клиент получил количество токена B ≥ minOut; выпускает чаевые (или возвращает средства Клиенту)

Результат объективен («получил ли Клиент ≥ minOut?»), что делает это решение идеальным для ERC-8183, в отличие от ребалансировщика.

1. Назначение и область применения

Агент-провайдер, который выполняет одно задание по Обмену-интенту за раз, маршрутизируя его через агрегацию PancakeSwap и доставляя целевой токен непосредственно Клиенту — и ничего больше.

2. Что агенту РАЗРЕШЕНО делать (список разрешённых возможностей)

#
Возможность
Поверхность
Примечания

A

Обнаружение открытых Job

BNBAgent SDK (реестр ERC-8183)

Только чтение; фильтрация до Job-Обменов, которые агент может выполнить

B

Получение котировки маршрута

Агрегация PancakeSwap (Aggregator API / Smart Router)

Только чтение; лучшая цена по всему V3

C

Принятие Job

BNBAgent SDK (Funded → committed)

Только если свежая котировка ≥ minOut и чаевые ≥ минимума

D

Исполнение Обмена

Маршрутизатор PancakeSwap

Входные данные берутся из эскроу Job; получатель = Клиент, в одной транзакции

E

Отправка результата

BNBAgent SDK (→ Submitted)

Хеш транзакции исполнения как подтверждение

F

Получение чаевых

Эскроу ERC-8183 / x402

Только после того, как Оценщик помечает Job как Terminal

Результат каждого исполнения идёт непосредственно Клиенту. Единственный заработок агента — чаевые Job.

3. Жёсткие ограничения (условия для включения в список)

Ограничение
Правило

Никогда не принимай то, что не можешь выполнить

Принимай Job только если свежая котировка превышает minOut. Если нет — оставь Job в статусе Funded для другого Провайдера.

Повторная котировка при исполнении

Получи новую котировку непосредственно перед исполнением; откажись, если маршрут больше не превышает minOut (никаких устаревших котировок).

Атомарное исполнение

Вывод из эскроу → Обмен → доставка Клиенту в одной транзакции, получатель = Клиент. Агент никогда не должен держать средства Клиента после неудачного шага.

Проскальзывание

Проскальзывание при исполнении ограничено; доставленная сумма должна быть ≥ minOut с учётом проскальзывания, иначе транзакция откатывается. Никогда amountOutMin = 0.

Дедлайн

Короткий дедлайн транзакции исполнения (≤ 5 мин); соблюдение собственного дедлайна Job.

Минимальные чаевые / максимальная стоимость

Не принимай Job ниже минимума чаевых или выше лимита стоимости на Job.

Белый список токенов

Обслуживай только Job, токены которых есть в списке токенов PancakeSwap (защита от мёдовых ловушек / фейковых токенов).

Одновременность одного Job (v1)

Выполняй один Job за раз; никакого перенасыщения.

Предварительная проверка газа

Убедись в наличии достаточного количества BNB для полного исполнения перед принятием.

Идемпотентность

Никогда не отправлять повторно и не выполнять повторно Job, уже находящийся в статусе Submitted/Terminal.

Если какое-либо правило не может быть выполнено, пропусти Job — никогда не форсируй исполнение.

4. За пределами области применения — агент НЕ ДОЛЖЕН

  1. Использовать средства Клиента для чего-либо, кроме указанного Обмена. Получатель результата всегда Клиент.

  2. Использовать собственные средства / нести риск основного долга. v1 работает только с выводом из эскроу — маршрутизирует escrowed input Клиента; не выполняет ордера из собственного баланса.

  3. Маршрутизировать через контракты, не являющиеся PancakeSwap или непроверенные, или исполнять вне агрегации PancakeSwap.

  4. Обслуживать Job с токенами, не входящими в белый список, или (v1) любыми масштабированными UI / RWA токенами (§5).

  5. Использовать Кредитное плечо, перпы, маржу или кредитование.

  6. Отправлять результат, который агент не выполнил (никакой ложной аттестации) или оценивать собственные Job (конфликт интересов).

  7. Вызывать какую-либо функцию владельца/администратора в PancakeSwap или контрактах ERC-8183.

  8. Держать постоянные одобрения токенов за пределами одного исполнения; ограничивай одобрения суммой Job.

5. Логика, специфичная для PancakeSwap (корректность приложения)

  • Маршрутизируй через агрегацию PancakeSwap, а не через один пул — лучшее исполнение по V2 / V3 / Stable и есть основное ценностное предложение («лучшая цена получает чаевые»).

  • Атомарная доставка Клиенту путём установки recipient маршрутизатора на адрес Клиента; никогда двухшаговый «Обмен на себя, затем перевод».

  • Актуальность котировки — on-chain цена меняется между обнаружением и исполнением; получай новую котировку при исполнении (ограничение §3).

  • minOut указан в сырых единицах. Для масштабированных UI / ERC-8056 токенов (Binance Stock Tokens / RWA акции) сырое ≠ отображаемое; некорректная обработка незаметно недодоставляет. Исключи масштабированные UI токены из v1, пока инженеры не подтвердят корректность обработки сырых единиц на всём пути.

  • Минимум проскальзывания при исполнении Обмена должен быть вычислен так, чтобы доставленная сумма ≥ minOut с учётом разделения чаевых/комиссии.

6. Поведение при сбое и восстановлении

  • Котировка не проходит minOut при исполнении → прерви до/одновременно с выводом из эскроу; Job остаётся в статусе Funded для другого Провайдера. Никакого частичного состояния.

  • Job уже Submitted/Terminal → пропусти (идемпотентность).

  • Транзакция исполнения откатывается → Job остаётся доступным для других; агент фиксирует сбой и продолжает.

  • Повторные сбои на одном Job → занести Job в локальный чёрный список и предупредить, а не циклически повторять попытки.

7. Точки интеграции (часть BNB / ERC-8183)

Предоставляются BNB Agent Studio / BNBAgent SDK, а не разрабатываются PancakeSwap — но спецификация зависит от них:

  • Жизненный цикл Job (обнаружение Open → принятие Funded → Submitted → получение чаевых) через BNBAgent SDK.

  • Идентичность Провайдера через ERC-8004.

  • Эскроу + выплата через эскроу ERC-8183 / x402.

  • Оценщик — предикат должен быть «баланс токена B у Клиента увеличился на ≥ minOut». Уточни у BNB кто запускает Оценщика (нейтральный/протокол или Клиент) и что предикат принудительно исполним on-chain.

8. Рекомендуемая позиция v1 и открытые вопросы

  1. Только вывод из эскроу, один Job за раз, только белый список токенов, никаких масштабированных UI токенов. Наименьшая безопасная поверхность для запуска.

  2. Подтверди интерфейс Обмена PancakeSwap — HTTP API агрегатора (aggr) или Smart Router SDK. Комментарий Jerry гласит «использовать pcs aggr api»; нужно подтверждение того, какой вызывает агент, так как это меняет интеграцию (и нужен ли раздел об агрегации в руководстве).

  3. Подтверди механику эскроу с BNB — может ли Провайдер вывести escrowed input Клиента для маршрутизации Обмена, и является ли доставка-Клиенту принудительно исполнимым результатом?

  4. Подтверди владельца Оценщика и предикат (§7).

Подтверждение инженеров перед запуском: атомарная маршрутизация вывода из эскроу → Обмен → доставка-Клиенту; повторная котировка при исполнении; математика minOut-после-проскальзывания; принудительное исполнение белого списка; идемпотентная обработка Job.

PreviousСоздание торговых агентов на PancakeSwap V3NextТокеномика CAKE

Last updated

Was this helpful?