skills-web3: двенадцать навыков для агента-казначея

Марк — сетевой инженер, и у него есть агент-казначей, которого команда в шутку зовёт Кассиром. Кассир умеет читать логи и писать в чат, но стоило попросить «покажи, сколько у нас USDC на Base», как он честно ответил: «не знаю, как». Первый вопрос Марка был таким же, как у тебя: неужели под каждую сеть и каждый сервис придётся писать свою обвязку?

Нет. @dzhechkov/skills-web3 — это пакет из двенадцати навыков (skills), и каждый навык — инструкция для агента, как работать с одним web3-сервисом: узлом RPC, аналитикой кошелька, обменом между цепочками, реестром личностей агентов, социальной сетью. Навык — не библиотека и не SDK, а текстовый файл SKILL.md с разделами «когда использовать», «настройка», «подводные камни» и готовыми фрагментами кода. Агент читает его и делает работу сам.

Ставится пакет тремя способами (README, раздел Install):

1. dz init --target claude-code --preset web3 — весь пакет целиком;
2. dz init --target claude-code --select quicknode,zerion,symbiosis — только нужные навыки;
3. npm install @dzhechkov/skills-web3 — как обычную npm-зависимость.

Главное, что меняет привычки: навыки включаются сами по пусковым фразам. У каждого SKILL.md в шапке (frontmatter — служебный блок в начале файла) записаны описание и триггеры: фразы, по которым агент понимает, что этот навык подходит к задаче. Марк не пишет «загрузи навык zerion», он говорит «покажи баланс кошелька» — и агент сам подхватывает zerion. «Поставь мне основное ENS-имя» → ens-primary-name, «обменяй токены через Symbiosis» → symbiosis. Точные пусковые фразы навыка показывает dz info <skill-id>, а найти навык по слову помогает dz registry search <term>.

Все двенадцать навыков пришли из gitlawb/banker-skills (проект BankrBot, лицензия MIT) и приведены к стандарту agentskills.io: у каждого есть уровень доверия trust_tier «Validated», схема выходных данных и шаблон проверки. Ссылки, чтобы не искать: пакет на npm и репозиторий DZ Harness Hub.

Компромисс: ты получаешь двенадцать сервисов одной командой и не пишешь обвязку — но навык описывает чужой API, и когда сервис меняет адрес или контракт, навык может отстать. Хорошая новость: авторы пакета это знают, и в нескольких навыках прямо написано «TODO: не проверено» там, где живой адрес не подтвердился. Ты ещё встретишь такие пометки в этом курсе — и научишься доверять им больше, чем красивым таблицам.

Кассир живёт на Base — это L2-сеть поверх Ethereum (второй уровень: транзакции дешевле, а безопасность наследуется от основной сети). Но часть денег команды лежит на Ethereum, чуть-чуть на Solana, и Марк спрашивает: «а навыки вообще туда дотянутся?». Прежде чем читать дальше, прикинь сам: сколько из двенадцати навыков, по-твоему, работают с Solana? Запомни число — сверим.

README пакета отвечает таблицей «Chain Coverage». Перескажу её так, чтобы картинка сложилась:

• Base — все 12 навыков. Это единственная цепочка, которую понимает каждый навык пакета.
• Ethereum — 7: quicknode, zerion, symbiosis, ens-primary-name, erc-8004, trails, bankr.
• Polygon — 5: quicknode, zerion, symbiosis, trails, bankr.
• Arbitrum — 5: zerion, symbiosis, ens-primary-name, trails, bankr.
• Solana — 3: quicknode, zerion, bankr.
• Optimism — 3: zerion, symbiosis, ens-primary-name.
• 54+ остальных — только symbiosis.

Сверь свою догадку: Solana покрывают три навыка, и все три — про чтение и торговлю (узел, аналитика кошелька, торговый агент). Ни личности, ни приватности, ни социальной сети на Solana в этом пакете нет.

Почему именно Base у всех двенадцати. Пакет вырос из BankrBot — торгового агента, который живёт на Base, и почти все сервисы вокруг него (Veil, Hydrex, ERC-8004-реестры, оплата x402 в USDC) выбрали ту же сеть. Для Марка это означает простое правило: если Кассир держит рабочие деньги на Base, любой навык из пакета к ним дотянется. Если на другой цепочке — сначала сверься с картой.

Два уточнения, которые карта не показывает, а навыки показывают:

1. Veil и Hydrex работают только на Base — это не ограничение README, это ограничение самих протоколов (см. их SKILL.md, раздел When to Use).
2. Покрытие «поддерживает цепочку» не значит «делает на ней всё»: ens-primary-name на Base ставит обратную запись имени, а аватар всё равно пишет в основную сеть Ethereum. Об этом — в секции про ENS.

Компромисс: единый знаменатель Base упрощает жизнь агенту — одна сеть, один USDC-кошелёк для оплаты, одинаковые адреса контрактов. Цена — за пределами Base покрытие быстро редеет, и мультичейн-казначейство придётся собирать из трёх-четырёх навыков, а не из одного.

Марк начинает с самого простого: пусть Кассир раз в час проверяет баланс на Base и Ethereum. Для этого нужен RPC-узел — сервер, который отвечает на вопросы к блокчейну: сколько на адресе, прошла ли транзакция, сколько будет стоить газ. Раньше это значило «зарегистрируйся у провайдера, получи ключ, выбери тариф». Навык quicknode предлагает второй путь, и он звучит почти неправдоподобно.

x402 — оплата за каждый запрос без ключа. Название — от HTTP-кода 402 Payment Required, который в вебе тридцать лет лежал без дела. Работает так: агент шлёт запрос, узел отвечает «402, заплати столько-то», клиентская библиотека сама платит USDC на Base и повторяет запрос. Ни регистрации, ни ключа, ни тарифа. По таблице цен в навыке: запрос к Base — около $0.00005, к Ethereum или Solana — около $0.0001.

Подключается в три строки:

npm install x402-axios

const client = wrapAxiosClient(axios, {
  paymentWallet: { privateKey: process.env.WALLET_PRIVATE_KEY, chain: "base" }
});
await client.post("https://api.quicknode.com/x402/v1/base/mainnet",
  { jsonrpc: "2.0", method: "eth_blockNumber", params: [], id: 1 });

Кошелёк с USDC на Base — единственное, что нужно заранее. Конечные точки одинаковы по форме: /x402/v1/<сеть>/mainnet для base, ethereum, polygon, solana, arbitrum, optimism и ещё 70+ сетей.

Второй режим — API-ключ. Обычная регистрация, месячный тариф, адрес вида https://your-endpoint.quiknode.pro/your-api-key/. Навык говорит прямо, когда его выбирать: для боевых приложений с постоянной высокой нагрузкой, где стабильные лимиты и месячная плата выгоднее оплаты за штуку.

Сверх голого RPC навык открывает дополнения из маркетплейса QuickNode — методы qn_*: qn_getWalletTokenBalance (все токены кошелька), qn_fetchNFTs, qn_estimatePriorityFees. Их надо включить на панели провайдера, иначе узел ответит ошибкой -32601 Method Not Found.

Чего навык не делает — и говорит об этом первым. Это чтение и оплата, не подпись и не отправка сделок. Обменять токены через quicknode нельзя: для этого есть symbiosis, trails и bankr. Таблица ошибок из навыка, которую Марк повесил рядом с монитором:

• 402 — x402 договаривается сам; если запрос всё равно падает, в кошельке кончился USDC;
• 429 — лимит; откатывайся с растущей задержкой;
• -32000 — ошибка выполнения: проверь параметры, чаще всего формат адреса;
• -32601 — метод не найден: включи дополнение или проверь имя.

Компромисс: x402 даёт агенту доступ к 77+ сетям за минуту и без единого ключа, а платишь ровно за то, что спросил. Цена — приватный ключ платёжного кошелька лежит в переменной окружения у самого агента, и на большой нагрузке копейки за запрос складываются в сумму, которую месячный тариф покрыл бы дешевле. Марк выбрал x402 для почасовых проверок и записал: «перейти на ключ, когда запросов станет больше тысячи в день».

Узел из прошлой секции ответил Марку честно и бесполезно: 0x1bc16d674ec80000. Это баланс в wei, шестнадцатеричный, без названия токена и без цены. Кассиру же нужен ответ «на кошельке 2 ETH и 340 USDC, за сутки минус 1,8%». Между сырым узлом и таким ответом лежит целый слой, и навык zerion — ровно про него.

Zerion отдаёт интерпретированные данные кошелька: не hex, а портфель — стоимость, позиции по токенам, прибыль и убыток (PnL), историю транзакций, NFT, графики. И всё это уже приведено к одному формату по 41+ цепочке, включая Solana. Марку не нужно ходить в каждую сеть отдельно: один адрес — один ответ.

Первая команда из навыка (раздел CLI Quick Start):

export ZERION_API_KEY="zk_dev_xxxxx"
curl -s "https://api.zerion.io/v1/wallets/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045/portfolio" \
  -u "$ZERION_API_KEY:" | jq '.data.attributes'

Грабли, на которые Марк наступил первыми: двоеточие после ключа. Авторизация у Zerion — HTTP Basic, но ключ идёт в поле имени пользователя, а пароль пустой. Флаг -u "$ZERION_API_KEY:" с двоеточием в конце — это и есть «пароль пустой». Забыл двоеточие или положил ключ в поле пароля — получишь 401 и час поисков. Навык выносит это первым пунктом раздела Gotchas.

Что ещё есть за тем же ключом, все под /v1/wallets/<адрес>/:

1. positions/ — позиции по токенам, с фильтрами only_simple / only_staked / only_locked;
2. transactions/ — история со страницами по курсору page[after];
3. pnl/ — реализованная и нереализованная прибыль;
4. charts/ — стоимость портфеля за период от 1d до max;
5. nft-positions/ — NFT с ценой пола коллекции.

Три честных ограничения из навыка. Первое: бесплатный тариф — 60 запросов в минуту и 5 вебхуков; веер «позиции + PnL + график» на каждый кошелёк выжигает лимит быстро, смотри заголовок X-RateLimit-Remaining. Второе: идентификаторы цепочек — строки (base, ethereum, binance-smart-chain), а не числа вроде 8453; в filter[chain_ids] число не сработает. Третье: данные индексированы, а не финальны — свежие транзакции могут отставать от головы цепочки; для расчётов, где на кону деньги, сверяйся с узлом.

Связка, ради которой Zerion попал в пакет: исследуй здесь — исполняй в Bankr. Zerion умеет дать котировку обмена (/v1/swap/quote/) и даже собрать неподписанную транзакцию (/v1/swap/transaction/), но не подписывает и не отправляет. Навык показывает шаблон: позиции → PnL → котировка в Zerion, потом отправка через Bankr. Котировка живёт недолго — перед подписью запроси её заново.

Компромисс: Zerion экономит агенту десятки вызовов к разным сетям и отвечает по-человечески, но ответ приходит из индекса стороннего сервиса с задержкой, а бесплатный тариф тесен. Кассир у Марка получил читающий ключ Zerion и правило: «отчёт — из Zerion, а перед тем как двигать деньги — сверка с узлом».

У команды Марка 0,1 ETH застряли на Base, а платить подрядчику надо в USDC на Ethereum. Раньше это было два действия: мост между сетями, потом обмен на DEX, и в обоих местах можно потерять деньги. Навык symbiosis делает из этого одно действие: кросс-чейн своп — обмен токена на одной цепочке на токен на другой, маршрут между ними сервис подбирает сам по 54+ блокчейнам.

Своп в четыре шага, и порядок не меняется никогда:

1. Котировка — POST https://api-v2.symbiosis.finance/crosschain/v1/swap с описанием входа и выхода. В ответ — ожидаемая сумма, маршрут, комиссия, ценовое влияние и готовый объект tx.
2. Разрешение — если на входе ERC-20-токен, надо разрешить контракту из поля approveTo тратить нужную сумму (approve). Для родного токена сети (ETH, MATIC) с адресом 0x000…000 шаг пропускается.
3. Обмен — подписать и отправить tx из котировки в сеть-источник.
4. Отслеживание — опрашивать GET /crosschain/v1/tx/{hash}, пока статус не станет completed. Подтверждение в сети-источнике — ещё не конец: деньги идут через другую цепочку.

В навыке два готовых скрипта на Python: symbiosis_quote.py печатает котировку, symbiosis_swap.py проводит все четыре шага с локальным ключом и web3.py. Пример в них ровно наш: 0,1 ETH на Base (chainId 8453) → USDC на Ethereum (chainId 1).

Проскальзывание — в базисных пунктах. Проскальзывание — допустимая разница между обещанной и фактической ценой. Symbiosis принимает его числом: 300 = 3%. Таблица из навыка:

• 50 (0,5%) — стейблкоин в стейблкоин;
• 300 (3%) — обычный обмен, значение по умолчанию;
• 500 (5%) — волатильный токен, тонкая ликвидность;
• 1000 (10%) — только в крайнем случае.

Марк сначала поставил 3 и получил SLIPPAGE_TOO_LOW на первой же попытке: он написал проценты, а сервис прочитал 0,03%. Ошибки из таблицы навыка: INSUFFICIENT_LIQUIDITY — уменьшить сумму или сменить маршрут; AMOUNT_TOO_LOW — ниже минимума; UNSUPPORTED_PAIR — маршрута нет, проверить пару; APPROVAL_FAILED — не хватило разрешения или газа.

Второй путь — без своего ключа. Если у агента есть кошелёк Bankr, навык показывает вызов POST https://bankr.bot/api/v1/submit с type: "cross-chain-swap" и protocol: "symbiosis": разрешение, подпись и отправку берёт на себя Bankr. Это и есть агентный режим: Кассир не держит приватный ключ, он держит ключ API.

Компромисс: один вызов вместо «мост плюс DEX» и автоматический маршрут по 54+ цепочкам — против того, что ты платишь комиссию агрегатора, ждёшь завершения в другой сети и доверяешь чужому маршруту. Для обмена внутри одной сети навык прямо советует взять однопоточный агрегатор, а не Symbiosis.

Три навыка подряд — zerion, symbiosis, а дальше trails, veil и quotient — в какой-то момент говорят одно и то же: «а отправку сделай через Bankr». Пора разобраться, что это. Прежде чем читать, ответь себе на вопрос, у которого нет единственно правильного ответа: какой ключ ты дал бы агенту, который двигает деньги команды, — полный или только на чтение? Держи ответ в голове до конца секции.

Bankr — платформа торгового агента с кастодиальным кошельком. Кастодиальный — значит приватный ключ хранит платформа, а не ты; агент управляет кошельком через ключ API. Взамен Bankr берёт на себя то, что в блокчейне больнее всего: подбор маршрута с защитой от MEV (когда чужие боты вклиниваются в твою сделку и отбирают часть цены), газ, nonce, мосты между Base, Ethereum, Polygon, Arbitrum, BNB, Unichain, World Chain и Solana.

Вход простой: npm install -g @bankr/cli, потом bankr login --email you@example.com с кодом из письма, ключи и профили — на terminal.bankr.bot. В скриптах — bankr login --api-key <key> из переменной окружения.

Две прослойки API, и путать их нельзя:

• Wallet API — синхронный. Создать кошелёк, спросить баланс, найти токен, посмотреть портфель. Ответ приходит сразу, внутри ответа: bankr wallet balance --chain base.
• Agent API — асинхронный. Обмен, мост, лимитный ордер, стоп-лосс, DCA, TWAP. В ответ приходит не результат, а taskId; дальше опрашиваешь GET /api/v1/agent/task/{taskId} или bankr agent task <taskId>, пока статус не станет completed или failed.

Марк наступил ровно сюда: Кассир отправил bankr agent swap --from USDC --to ETH --amount 100 --chain base, получил 200 и отчитался «обменял». Через минуту сделка упала по ликвидности, а в отчёте уже стояло «готово». Навык предупреждает первым пунктом Gotchas: ответ на отправку — не результат; результат — статус задачи по taskId.

Что ещё умеет Agent API одной строкой:

bankr agent bridge --token USDC --amount 100 --from ethereum --to base
bankr agent stop-loss --token ETH --trigger 2800 --chain base
bankr agent dca --buy ETH --spend 100 --frequency daily --chain base
bankr agent submit --commit-id <id> --signed-tx <hex>

Последняя команда — та самая, через которую Trails, Veil и Symbiosis отдают подписанные транзакции.

Теперь про ключ. У Bankr есть три предохранителя, и навык перечисляет их в разделе Safety: профили с изолированными кошельками (bankr profile create --name "dca-bot" — деньги одного профиля недоступны другому), ключи только на чтение (bankr api-key create --scope read-only) и белый список IP для ключей с правом исполнения. Марк ответил на вопрос из начала так: Кассир получил ключ на чтение для отчётов, а ключ на исполнение живёт в отдельном профиле с лимитом и белым списком адресов. Твой ответ мог быть другим — важно, что ты его обосновал.

Четыре предупреждения из навыка, которые стоят денег: плечо до 50x на бессрочных контрактах и до 100x на отдельных парах — ликвидация от малейшего движения, ставь стоп-лосс; стоп-лосс и лимит срабатывают по ценовому фиду, а не гарантируют цену исполнения; мост со статусом completed в сети-источнике не значит, что деньги уже доступны в сети назначения; у Solana нет EVM-идентификатора цепочки, логика «по chain id» должна её обрабатывать отдельно. И ещё одно, тихое: встроенный LLM-шлюз (bankr llm chat) тарифицируется кредитами — перед длинным циклом рассуждений проверь bankr llm credits.

Компромисс: Bankr снимает с агента ключи, газ, MEV и маршруты — за это ты доверяешь деньги кастодиану и живёшь с асинхронностью, где каждый результат надо дождаться по taskId. Для разовой котировки или чтения без сделки навык честно советует взять что-то полегче.

Symbiosis из пятой секции требовал от Кассира собирать транзакцию по частям. Навык trails предлагает другой уровень разговора: агент описывает намерение (intent) — «хочу из 1000 USDC на Base получить ETH на Arbitrum с проскальзыванием 0,5%», а движок Sequence Trails сам подбирает маршрут, отдаёт транзакции на подпись и ведёт до квитанции. Тот же движок умеет находить доходные пулы и хранилища (ListEarnPools, ListYieldVaults) и вносить в них депозит тем же путём.

Жизненный цикл намерения — пять шагов, строго по порядку, каждый должен завершиться до следующего:

1. QuoteIntent — описываешь намерение (тип, цепочки, токены, сумма, slippageBps), получаешь quoteId, ожидаемый выход и маршрут. Котировка живёт 30 секунд.
2. CommitIntent — фиксируешь маршрут по quoteId и адресу кошелька, получаешь commitId и транзакции на подпись. Коммит живёт 60 секунд.
3. Отправка через Bankr — bankr agent submit --commit-id <id> --signed-tx <hex> или POST /api/v1/agent/submit.
4. ExecuteIntent — запускаешь исполнение по commitId, получаешь intentId.
5. WaitIntentReceipt — ждёшь квитанцию по intentId с timeoutMs: хэши транзакций, фактический выход, статус.

Марк первый раз запросил котировку, пошёл проверять маршрут глазами, вернулся через минуту — и получил отказ на коммите. Навык называет это первым в Gotchas: окна коротки нарочно, не откладывай коммит после котировки и отправку после коммита. Цена ошибки — просто новая котировка, но автоматизация, которая «сначала логирует, потом действует», в эти окна не попадёт.

Четыре правила, каждое из навыка:

• Суммы — в базовых единицах. 1 USDC = "1000000" (6 знаков), 1 ETH = "1000000000000000000" (18). Родной токен сети обозначается адресом 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.
• Проскальзывание — slippageBps, по умолчанию 50 (0,5%), потолок 500 (5%). Значение выше потолка отклоняется, а не обрезается.
• Отправка — только через Bankr. Транзакции из CommitIntent нельзя слать прямо в узел: Bankr отвечает за nonce, газ и защиту от MEV, а прямая отправка рассинхронизирует состояние намерения.
• Квитанция — не финальность. Обмен внутри одной сети занимает около 15 секунд, мост между сетями — от 2 до 20 минут. Ставь timeoutMs щедро, и таймаут читай как «ещё идёт», а не «упало».

Ключ один на всё: BANKR_API_KEY в заголовке Authorization: Bearer авторизует и Trails, и Bankr. Это общий секрет, и навык просит не печатать его в логи и квитанции — только из переменной окружения.

Компромисс: намерение экономит агенту ручную сборку транзакций и даёт полный цикл «коммит — исполнение — квитанция» с отслеживанием; платишь зависимостью от Bankr на отправке и дисциплиной коротких окон. Для простого чтения баланса или вызова контракта Trails — лишний слой, навык сам отсылает к RPC-навыку.

Кассир научился читать и двигать деньги, и тут команда задала Марку вопрос, который он не ждал: «а кто вообще этот агент? Как сервис на другом конце поймёт, что это наш Кассир, а не чужой бот с нашим ключом?» Ответ в пакете разложен на два навыка: erc-8004 даёт агенту паспорт, siwa — способ предъявить его при входе.

ERC-8004 — стандарт личности агента в цепочке, три реестра:

1. Identity Registry — ERC-721-токен (NFT) на каждого агента: уникальный номер плюс agentURI — ссылка на профиль (IPFS, HTTP или data-URI). Регистрация — вызов register(string agentURI), обновление — setAgentURI.
2. Reputation Registry — отдельный контракт, куда пишут и откуда читают отзывы об агенте.
3. Validation Registry — отдельный контракт для независимых проверок.

Профиль — JSON: имя, описание, модель, список возможностей, цепочки, уровень автономии (supervised), контакт. Где его хранить — выбор из таблицы навыка: IPFS неизменяем, но требует пиннинга (если пиннинг пропал, tokenURI() вернёт хэш, а содержимого не будет); HTTP — под полным контролем, но изменяем и требует аптайма; data-URI — целиком в цепочке, дорого и с ограничением размера; 8004.org — управляемый хостинг, зато централизованный. Регистрация на Base стоит около $0.01.

А теперь самое важное место в навыке — и оно не про код. В разделе Contract Addresses стоит пометка «TODO: unverified»: адрес реестра, который раньше значился в навыке, не содержит байткода на Base — eth_getCode возвращает 0x. Слать туда транзакции нельзя. Официального SDK нет: пакет @8004/sdk, на который ссылались раньше, на npm не существует. И функции bridge() в стандарте нет — старая версия навыка описывала «перенос личности между цепочками за 0.001 ether», это было выдумкой, и её вычистили. Личность — отдельная на каждой цепочке.

Что это значит на практике: Марк перед регистрацией находит адрес реестра для своей цепочки сам, проверяет его командой cast code <addr> --rpc-url <rpc> (байткод должен быть непустым) и подставляет через REGISTRY_BASE. Навык, который говорит «я не проверил», ценнее навыка с красивой, но мёртвой таблицей.

SIWA — Sign-In With Agent, вход по подписи кошелька. Это родственник SIWE (вход по Ethereum-кошельку), но для автономных агентов. Ставится npm install @buildersgarden/siwa. Три шага: сервис даёт вызов с nonce и сроком, агент собирает сообщение createSiwaMessage({domain, address, chainId: 8453, nonce, expirationTime, resources: ['urn:capability:trade', 'urn:capability:read']}) и подписывает его через bankr wallet sign --message ... --chain base; сервис проверяет verifySiwaMessage() и выдаёт токен. Есть готовые прослойки для Next.js, Express, Hono и Fastify.

Четыре правила из Gotchas навыка siwa, каждое — отдельная дыра, если забыть:

• verifySiwaMessage() возвращает результат, а не бросает исключение: проверяй result.success, не оборачивай в try/catch «на удачу»;
• nonce проверяется на сервере (NonceStore): без него подпись можно перехватить и повторить;
• expirationTime надо уважать — в примере окно 10 минут;
• chainId в подписи должен совпадать с ожидаемым сервисом.

И главное: возможности в resources — это заявка агента, а не разрешение. Сервис обязан пересечь запрошенное со своим списком допустимого, прежде чем выдать trade, transfer или тем более admin.

Компромисс: паспорт даёт агенту проверяемую личность и репутацию, а SIWA — вход с точечными правами вместо общего ключа API. Платишь тем, что стандарт молод: канонического адреса и SDK нет, каждую цепочку регистрируешь отдельно, а безопасность входа целиком зависит от того, проверил ли сервер nonce, срок и права.

Паспорт у Кассира теперь есть, но в любом обозревателе он всё ещё 0xd8dA…96045. Марк хочет, чтобы там было kassir.team.eth. Он открывает навык ens-primary-name и с ходу попадает на маленький сюрприз: одной записи мало, их две, и направлены они в разные стороны.

ENS — служба имён Ethereum, аналог DNS для адресов. У имени два разрешения:

• прямая запись — name.eth → 0xАдрес; её ставит владелец имени в реестре ENS;
• обратная запись — 0xАдрес → name.eth; её ставит владелец адреса через контракт Reverse Registrar. Именно она называется основным именем (primary name), и именно её пишет этот навык.

Почему обязательно обе? Попробуй представить, что обратной записи достаточно. Тогда Марк мог бы поставить своему адресу основное имя vitalik.eth — и кошельки показывали бы его как Виталика. Защита от подмены в том, что клиент верит обратной записи, только если прямая запись имени указывает на тот же адрес. Ты не можешь присвоить чужое имя, пока его владелец не направит его на тебя. Отсюда первый пункт Gotchas: сначала прямая запись, потом основное имя — иначе кошельки сочтут обратную запись непроверенной и проигнорируют.

С 2024 года основное имя можно ставить на L2 — Base, Optimism, Arbitrum, Linea, Scroll — через свой Reverse Registrar в каждой сети, дешевле, чем в основной сети. Скрипт из навыка сводится к одной команде Foundry:

cast send "$CONTRACT" "setName(string)" "$ENS_NAME" \
  --rpc-url "$RPC" --private-key "$PRIVATE_KEY"

Пять L2 делят один адрес L2ReverseRegistrar — 0x0000000000D8e504002cC26E3Ec46D81971C1664 (сверено с docs.ens.domains), в основной сети он другой. И тут же навык передаёт предупреждение самого ENS: не зашивай эти адреса — они могут смениться; разрешай по ENSIP-19 или хотя бы сверяй с документацией перед cast send.

Второй сюрприз ждёт на аватаре. Марк хотел заодно повесить картинку — и выяснил, что аватар живёт в основной сети, а не на L2: setText(namehash, "avatar", uri) пишется в публичный резолвер Ethereum (0x231b0Ee1…), отдельной транзакцией и с отдельным газом. Основное имя на Base и аватар — два разных действия в двух разных сетях. Форматы аватара — HTTPS, ipfs://, NFT вида eip155:8453/erc721:0xКонтракт/tokenId (NFT должен принадлежать владельцу имени, иначе клиент покажет пустоту) и data-URI.

Чего навык не делает, и говорит об этом сразу: не регистрирует и не продлевает имена, не ставит прямую запись. Он предполагает, что имя уже есть и уже указывает на твой адрес. И общее для всех скриптов пакета: PRIVATE_KEY читается из окружения в открытом виде — для агента заведи отдельный малоценный ключ.

Компромисс: основное имя на L2 стоит копейки и делает адрес агента читаемым в каждом кошельке и обозревателе; взамен нужно помнить о двух записях в двух направлениях, двух сетях для имени и аватара, и об адресах контрактов, которые ENS просит не зашивать.

Команда хочет, чтобы Кассир публиковал недельный отчёт не только в чат, но и в Farcaster — децентрализованной социальной сети, где аккаунт привязан к кошельку, а не к почте. Навык neynar — REST-API к ней: пользователи, ленты, публикации, реакции, поиск.

Четыре понятия, без которых не прочитать ни один ответ API:

• FID — числовой идентификатор пользователя, неизменяемый;
• каст (cast) — публикация: до 320 символов, до 2 вложений-ссылок, можно указать канал и родительский каст для ответа;
• канал — тематическая лента со своим владельцем и правилами;
• фрейм — мини-приложение внутри каста.

Чтение — по ключу. Регистрируешься на dev.neynar.com, получаешь ключ, кладёшь его в заголовок x-api-key на каждый запрос. Дальше — GET /v2/farcaster/user/by_username?username=dwr.eth (в ответе FID, подписчики и verified_addresses — кошельки, которые пользователь подтвердил), ленты feed/trending, feed/channels?channel_ids=base,ethereum, feed/user/{fid}, полнотекстовый поиск cast/search?q=onchain%20identity. Бесплатный тариф — 300 запросов в минуту, на 429 — откат с задержкой не меньше секунды.

Запись — через подписанта. Постить, лайкать, подписываться от имени аккаунта агент может только через Signer UUID — управляемого подписанта Neynar, который подписывает сообщения протокола вместо тебя. Вот где Марк застрял на вечер: он создал подписанта, отправил POST /v2/farcaster/cast с signer_uuid и получил ошибку авторизации. Не лимит, не неверный ключ — свежий подписант рождается в состоянии pending_approval, и владелец Farcaster-аккаунта обязан его одобрить через панель или ссылку. Навык ставит это первым пунктом Gotchas, и не зря: ошибка выглядит как проблема с ключом, а причина — в неодобренном подписанте.

После одобрения публикация — одно тело запроса:

POST /v2/farcaster/cast
{ "signer_uuid": "…", "text": "Недельный отчёт казначейства…", "channel_id": "base" }

Ещё три правила из того же раздела:

1. Запись не мгновенна. Neynar принимает каст и асинхронно рассылает по хабам протокола; вернувшийся хэш может пару секунд не находиться ни в ленте, ни через GET /cast. Ответ 200 значит «принято», а не «все увидели».
2. Лимиты содержимого проверяй сам — 320 символов и 2 вложения; лишнее отклоняется при отправке, а не обрезается.
3. verified_addresses — то, что пользователь доказал Farcaster, а не то, что проверил ты. Пустой массив — «ничего не подтверждено», и чужой адрес приписывать FID нельзя.

И граница навыка, названная в первом же пункте When to Use: Neynar — про социальный граф и содержимое, не про балансы, обмены и контракты. Для тех — другие навыки этого пакета.

Компромисс: агент получает чтение и запись в открытую социальную сеть через один REST-API, без ручной подписи сообщений протокола; платишь тем, что писать можно только через одобренного владельцем подписанта, запись асинхронна, а ключ авторизует всё приложение и должен жить только на сервере.

У Кассира есть имя, паспорт и голос — и теперь каждый перевод подрядчику виден всему интернету вместе с суммой. Для части платежей команде это не годится. Навык veil — про Veil Cash, экранированный пул на Base для ETH и USDC. В этой секции решения принимаешь ты: Марк только показывает, где в навыке лежит ответ.

Как устроен экранированный пул. Деньги входят в него публичным депозитом, внутри ходят приватными переводами между экранированными адресами вида veil:base:0x<64 hex>, а выходят публичным выводом на любой адрес — и связь между входом и выходом снаружи не видна. Доказательство того, что у тебя есть право потратить сумму, даётся с нулевым разглашением (ZK-доказательство): ты доказываешь право, не показывая, какую именно монету тратишь. Внутри — модель UTXO: каждый депозит и перевод создаёт «непотраченные выходы», а потраченный помечается нуллификатором, не раскрывая, какой именно.

Пакет и инструменты: npm install @veil-cash/sdk — он же ставит CLI veil с командами init / register / deposit / withdraw / transfer / merge. Осторожно с именем: @veil-protocol/sdk — совсем другой проект, приватность на Solana, не имеющий отношения к Veil Cash. Навык честно предупреждает и о своих примерах: класс VeilClient в них — иллюстративный псевдокод жизненного цикла; настоящие сигнатуры — в SDK.md внутри пакета.

Жизненный цикл из одиннадцати шагов навыка, сжатый до сути:

1. Ключевая пара Ed25519 в ~/.veil/keypair.json (права 0600, никому не показывать) — это и есть твоя экранированная личность.
2. Депозит — через Bankr (type: "veil-deposit") или напрямую своим подписантом; USDC требует предварительного approve. Минимум 0,001 ETH или 1 USDC. Средства видны в пуле примерно через 2 минуты — идёт генерация доказательства.
3. Приватный перевод на чужой veil:base:… — ни отправитель, ни получатель, ни сумма в цепочку не попадают.
4. Вывод на публичный адрес; доказательство считается 5–30 секунд. С useRelayer: true получатель не платит газ — реле по умолчанию https://veil-relay.up.railway.app, переопределяется через RELAY_URL.
5. Слияние мелких UTXO (до 16 за раз), чтобы кошелёк не разбухал.

Таблица Troubleshooting из навыка — по сути готовые ответы на твои будущие решения: «Insufficient shielded balance» — UTXO ещё не подтверждены, подожди 2–5 минут; «Relayer unavailable» — useRelayer: false и плати газ сам; «UTXO already spent» — состояние разошлось, resync; «Proof generation failed» — удалить ~/.veil/state.db и пересинхронизировать; «Amount too small» — ниже минимума.

Границы, названные в When to Use: только ETH и USDC, только Base, только вход-выход из собственного пула — не обмен и не мост. Veil Cash также проверяет депозиты на соответствие требованиям до входа в пул (см. docs.veil.cash).

Компромисс: приватность перевода на публичной цепочке — редкая способность, и она достаётся ценой ожидания доказательств (минуты на депозит, секунды на вывод), одной сети и двух активов, локального секретного файла и доверия реле при бесплатном выводе. Если тебе нужен просто перевод — навык прямо отправляет к кошельковому навыку.

Команда Марка держит часть казны в пулах ликвидности на Base и хочет, чтобы Кассир голосовал за распределение наград. Навык hydrex — про протокол управления ликвидностью Hydrex. Перед чтением — короткая проверка себя: если сумма голосов по пулам вышла 9999 базисных пунктов из-за округления, что сделает контракт? Запиши ответ; вернёмся к нему.

Как это работает. Замораживаешь токены HYDX на срок от 1 до 208 недель и получаешь veHYDX — «голосующий» баланс, который считается так: сумма × срок в неделях / 208. Замок на четыре года даёт полный вес, на год — четверть. Вес тает по мере приближения конца замка, поэтому навык просит перечитывать живой баланс veHYDX из контракта перед каждой эпохой, а не брать из кэша.

Голоса — за эпоху и в базисных пунктах. Эпоха длится неделю. Держатели veHYDX распределяют свой вес по пулам, и доля голосов определяет долю эмиссии HYDX, которую пул получит на следующей неделе. Распределение задаётся в базисных пунктах (1 бп = 0,01%), и сумма по всем пулам должна равняться ровно 10000:

{ "votes": [ { "pool": "0xPoolA…", "weight": 4000 },
             { "pool": "0xPoolB…", "weight": 3500 },
             { "pool": "0xPoolC…", "weight": 2500 } ] }

Теперь ответ на вопрос из начала: контракт Voter отклоняет всё, что не равно 10000 — и 9999, и 10001. Навык советует после нормализации отдавать остаток от округления пулу с наибольшим весом. Марк написал скрипт по формуле из навыка (Score(pool) из базовой доходности с весом 0,4, комиссий с весом 0,3 и стимулов с остатком 0,3), нормализовал — и первую неделю голос не прошёл ровно из-за одного пункта. Сверь со своим ответом: угадал ли ты, что контракт откажет, а не округлит?

Эпоха переворачивается в четверг в 00:00 UTC, дедлайн голосования — среда 23:59 UTC. Голос, отправленный после переворота, молча уходит в следующую эпоху: автоматизация с опозданием пропускает цикл эмиссии, не получив ни одной ошибки. Награды можно забирать после каждого переворота.

Что ещё есть в навыке:

• Стратегии голосования — таблица из пяти: максимизация доходности, рост TVL, комиссионный доход, диверсификация и «наёмная» (за самые щедрые стимулы от сторонних протоколов).
• Множитель 1.3x к доходности для держателей veHYDX в тех пулах, где они сами дают ликвидность.
• ICHI-хранилища — односторонняя ликвидность: вносишь один токен, позицию ведёт хранилище.
• oHYDX — опцион, а не подарок. Награда за голос — право купить HYDX со скидкой: цена исполнения = рыночная × (1 − скидка), скидка задаётся управлением и обычно 50–90%. Если рынок ушёл ниже страйка, исполнять невыгодно; котируй скидку перед каждым исполнением.

И два честных предупреждения от навыка. Публичного REST-API у Hydrex нет: хост api.hydrex.finance, который раньше значился в навыке, не разрешается (NXDOMAIN), данные читаются через официальный SDK @hydrexfi/hydrex-sdk или прямо из контрактов Voter и veHYDX Lens. Часть адресов (Minter, oHYDX, Rewards Distributor) помечена «TODO: не проверено» — их надо разрешить через SDK или docs.hydrex.fi перед использованием. И индексированные данные пулов (TVL, APY, стимулы) могут отставать от цепочки вблизи переворота — для решений с деньгами сверяй voteWeight по контракту.

Компромисс: голос veHYDX превращает замороженную казну в доход — эмиссии, стимулы и множитель 1.3x; платишь заморозкой на срок, тающим весом, жёстким недельным ритмом с молчаливым пропуском и тем, что часть адресов тебе придётся подтвердить самому.

Последний навык пакета — quotient, рыночная аналитика для агента: недооценённые рынки с расчётной справедливой ценой (fairValue, confidence, signal), структурированные отчёты, сигналы аналитиков «купить / продать / держать». Оплата — как у QuickNode из третьей секции: x402, микроплатежи USDC на Base, либо ключ по подписке (Authorization: Bearer).

Пять шагов x402-запроса — навык оформляет их как чек-лист на каждый вызов:

1. Запрос с заголовком Authorization: x402.
2. Ответ 402 Payment Required с блоком paymentRequired: сеть, токен, сумма, адрес получателя, memo вида quotient:markets:mispriced:req_abc123 и expiresAt.
3. Подписать платёж — bankr wallet sign-payment --to … --amount 0.01 --token USDC --chain base --memo "…".
4. Повторить запрос с заголовками X-Payment-Proof и X-Payment-TxHash.
5. Получить 200 с данными и блоком payment.confirmed: true.

Правило, которое стоит денег: запросить цену до оплаты. Перед платными вызовами навык требует два «предполётных» запроса — GET /openapi.json (схема и цены в аннотациях) и GET /api/public/pricing (текущая цена каждой конечной точки: рынки 0.005, недооценённые 0.01, сигналы 0.015, отчёты 0.02 USDC в иллюстрации). Цены дрейфуют между сессиями — зашитое 0.01 однажды окажется недоплатой, а memo и получатель привязаны к конкретному запросу и истекают: подписал старый — проверка не пройдёт. И ещё: платёж проверяется в цепочке Base, так что x402-ответ не мгновенный; для частых или чувствительных ко времени запросов навык советует ключ.

А теперь то, ради чего эта секция стоит последней. Марк открыл навык и первым делом увидел не таблицу, а рамку: «TODO: unverified — документированный контракт API недостижим». Продукт существует (quotient.social, dev.quotient.social, docs.quotient.social разрешаются), хост api.quotient.social тоже, но каждый документированный путь на нём возвращает 404 — проверены /, /openapi.json и /api/public/pricing. Всё ниже рамки навык называет иллюстрацией: базовый URL, пути и формы ответов надо взять с портала разработчика и заменить перед первым запросом.

В учебниках такие врезки обычно пропускают. Здесь врезка — главное содержимое: без неё Кассир заплатил бы за 404. На протяжении курса ты видел ту же честность в erc-8004 (адрес без байткода, несуществующий SDK, выдуманный bridge()), в hydrex (мёртвый REST-хост, непроверенные адреса), в veil (псевдокод вместо сигнатур). Привычка, которую стоит унести из курса: в навыке сначала ищи раздел Gotchas и слова «TODO: unverified», и только потом — примеры кода.

Марк закрывает пакет так: Кассир читает кошельки через Zerion и узел через x402, двигает деньги через Symbiosis, Trails и Bankr, носит паспорт ERC-8004, входит по SIWA, подписан читаемым ENS-именем, пишет в Farcaster, платит приватно через Veil, голосует в Hydrex — а Quotient подключит, когда портал разработчика отдаст живые пути. Каждый из этих шагов он проверил тем же способом, что и ты: прочитал навык до конца, включая рамки.

Компромисс: оплата за запрос без подписки и аналитика, которой нет в сырых данных цепочки, — против задержки на подтверждение платежа, дрейфующих цен и, прямо сейчас, недостижимого контракта API. Секрет QUOTIENT_API_KEY — только из окружения: ключ тарифицируется помесячно, утечка — прямой счёт.