Перейти к основному содержанию
Эти сценарии показывают, как Claude использует инструменты Tenderly MCP Server, чтобы выполнять реальные задачи разработки. Если вы ещё не подключили сервер, сначала следуйте быстрому старту MCP Server. Вам не нужно вызывать инструменты по имени — просто опишите, что хотите, и Claude сделает всё остальное. Примеры примерно сгруппированы по видам деятельности:
  • Настройка и pre-flight: разворачивание сред, пополнение кошельков, проверка транзакций перед подписью.
  • Отладка и post-mortem: выяснение, почему транзакция упала, кто забрал средства или почему swap вернул меньше, чем ожидалось. Здесь особенно полезны инструменты продвинутой навигации по трассе.
  • Сценарии в Virtual Environment: имперсонация, многошаговое тестирование, снапшоты, путешествия во времени, переопределение балансов токенов.
  • Оптимизация и инспекция: разбивка газа, метаданные контрактов.

​
Создание Virtual Environment и пополнение кошелька

Что попросить:
“Создай Virtual Environment, форкнутый из Ethereum mainnet, и пополни мой кошелёк 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 на 100 ETH.”
Что делает Claude:
  1. Вызывает list_projects, чтобы найти ваши проекты, затем set_active_project, чтобы выбрать один.
  2. Вызывает get_networks, чтобы найти network ID для Ethereum mainnet.
  3. Вызывает create_vnet с network ID, создавая форкнутую среду. Новый Virtual Environment автоматически становится активным.
  4. Вызывает fund_account с адресом вашего кошелька, устанавливая баланс 100 ETH в hex wei. Работает автоматически с активным Virtual Environment.
  5. Возвращает детали Virtual Environment, включая URL Admin RPC и Public RPC, готовые для использования в Hardhat, Foundry или любой Web3-библиотеке.
Что вы получаете: Запущенный Virtual Environment, форкнутый из последнего состояния mainnet, пополненный кошелёк и RPC URL, которые можно подставить в конфиг вашего фреймворка разработки.

​
Симуляция swap на Uniswap

Что попросить:
“Симулируй swap 1 ETH на USDC в Uniswap V3 от 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 в Ethereum mainnet. Покажи ожидаемый выход и все переводы токенов.”
Что делает Claude:
  1. Вызывает simulate_transaction с адресом роутера Uniswap V3, адресом отправителя, calldata swap и 1 ETH в качестве value.
  2. Симуляция запускается на текущем состоянии mainnet и возвращает: статус success/revert, использованный газ и декодированное имя метода.
  3. Вызывает get_simulation_asset_transfers, чтобы показать все движения токенов — ETH на вход и USDC на выход.
  4. Вызывает get_simulation_balance_changes, чтобы показать чистое влияние на балансы с USD-значениями.
Что вы получаете: Точный выход USDC, стоимость газа и разбивку каждого перевода активов. Если swap упал бы (например, из-за слишком высокого slippage), вы получите декодированную причину revert.

​
Pre-flight проверка транзакции перед отправкой

Что попросить:
“Я собираюсь вызвать approve на 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, чтобы дать 0xE592427A0AEce92De3Edee1F18E0157C05861564 безлимитное allowance USDC. Симулируй сначала и покажи, какие approvals и изменения состояния это создаст.”
Что делает Claude:
  1. Вызывает simulate_transaction с вашим кошельком как отправителем, контрактом токена как получателем и calldata approve.
  2. Вызывает get_simulation_exposure_changes, чтобы показать каждое изменение approvals и allowance — кто получает доступ, к чему и в каком объёме.
  3. Вызывает get_simulation_state_changes, чтобы показать точные слоты хранилища, которые изменились.
Что вы получаете: Точный выданный approval (адрес spender, токен, сумма), дифф хранилища, подтверждающий изменение слота allowance, и статус успешности транзакции. Полезно каждый раз, когда вы взаимодействуете с незнакомым контрактом или хотите проверить calldata перед подписью.

​
Отладка упавшей ончейн-транзакции

Что попросить:
“Почему транзакция 0x6c5df5a1e6b34e2432ae19706e38a84239495cdbf40c2a9d4d79806443c4aa0d упала в Ethereum?”
Что делает Claude:
  1. Вызывает trace_transaction с хешем транзакции. Возвращает статус (false = revert), использованный газ, декодированное имя метода и сообщение об ошибке.
  2. Вызывает get_simulation_call_trace, чтобы получить полное внутреннее дерево вызовов — каждый вызов функции с декодированными именами, входами, выходами и указанием, какой конкретно вызов упал.
  3. Вызывает get_simulation_events, чтобы увидеть, какие события были эмитированы до точки revert.
  4. Опционально вызывает get_simulation_state_changes, чтобы увидеть, какое состояние было изменено до падения.
Что вы получаете: Ясное объяснение, какой именно внутренний вызов упал, декодированную причину revert (например, "ERC20: transfer amount exceeds balance") и полную трассу вызовов, чтобы увидеть путь исполнения, приведший к падению.

​
Поиск первопричины revert в глубоко вложенной транзакции

Что попросить:
“Транзакция 0x… упала в Ethereum. Это сложный DeFi-вызов с массой внутренних вызовов, найди фактическую ошибку и покажи путь, который к ней привёл.”
Что делает Claude:
  1. Вызывает trace_transaction для верхнеуровневой сводки и подтверждает revert.
  2. Вызывает find_failures, чтобы перечислить все упавшие вызовы в транзакции, а не только самый внешний. Это показывает как первоначальный revert, так и оборачивающие require/try-catch-падения.
  3. Вызывает get_error_path, чтобы вернуть цепочку виновников от корневого вызова вниз до самого глубокого упавшего вызова, с декодированными входами и выходами на каждом уровне.
  4. Если у какого-то узла всё ещё есть опущенные потомки, вызывает get_call_trace_node для конкретной позиции, чтобы развернуть его.
Что вы получаете: Точный контракт, функцию и декодированную причину revert на самой глубокой точке падения, плюс полную цепочку вызывающих, которая к ней привела. Гораздо быстрее, чем листать вывод get_simulation_call_trace из 200 вызовов.

​
Навигация по очень большой трассе

Что попросить:
“У этой транзакции сотни внутренних вызовов, и get_simulation_call_trace усечён. Помоги мне понять её структуру и углубиться в важную часть.”
Что делает Claude:
  1. Вызывает get_trace_stats, чтобы сообщить общее число вызовов, максимальную глубину, количество ошибок и уникальных контрактов — быстрая проверка размера, которая определяет стратегию.
  2. Вызывает get_trace_skeleton, чтобы получить сжатое дерево вызовов: имя функции, контракт, глубина и флаг ошибки для каждого узла, без декодированных аргументов.
  3. Определяет интересующее поддерево (падающая ветвь, конкретный протокол или подозрительный контракт) по значениям absolute_position из скелета.
  4. Вызывает get_call_trace_node, чтобы развернуть это поддерево с полными декодированными входами и выходами.
  5. Опционально вызывает get_subtree_events и get_subtree_state_changes, чтобы увидеть только события и диффы хранилища из этого поддерева.
Что вы получаете: Карту структуры транзакции, а затем полные детали только той её части, которая вас интересует, без загрузки тысяч вызовов в контекст.

​
Поиск в трассе конкретного контракта или функции

Что попросить:
“Вызывалась ли transferFrom на USDC в этой транзакции? Если да, покажи каждый такой вызов с декодированными аргументами.”
Что делает Claude:
  1. Вызывает search_call_trace с адресом USDC и transferFrom в качестве фильтров, возвращая только совпадающие вызовы с их декодированными входами, выходами и абсолютными позициями.
  2. Для интересных совпадений вызывает get_call_trace_node, чтобы получить полный вложенный контекст вокруг.
Что вы получаете: Точечный список совпадающих вызовов вместо полной трассы. Полезно для ответа на вопросы “случилось ли X” в больших транзакциях и для аудита, вызывался ли известный рискованный selector.

​
Отслеживание денег в транзакции

Что попросить:
“Для транзакции 0x… в Ethereum покажи, кто, что и кому отправлял по порядку, с USD-значениями.”
Что делает Claude:
  1. Вызывает get_transaction_fund_flow с хешем транзакции. Возвращает упорядоченные переводы токенов и нативных активов, каждый с адресами from/to и USD-значениями, плюс чистый поток по каждому адресу.
  2. Опционально вызывает get_contract_info для незнакомых адресов, чтобы идентифицировать их (роутер протокола, пул, treasury и т. д.).
Что вы получаете: Хронологическую денежную карту транзакции и чистый поток по адресам — идеально для понимания MEV-бандлов, незнакомых DeFi-взаимодействий или проверки, что multi-hop swap двигал средства как ожидалось. Только для ончейн-транзакций.

​
Отладка упавшего batch-исполнения Safe multisig

Что попросить:
“Наше batch-исполнение Safe в 0x… упало в Ethereum. В batch 12 вызовов. Какой из них на самом деле упал и почему?”
Что делает Claude:
  1. Вызывает trace_transaction, чтобы подтвердить revert и получить верхнеуровневый метод (execTransaction или multiSend).
  2. Вызывает get_trace_stats — batch’и Safe быстро превращаются в большие трассы, так что статистика определяет следующий шаг.
  3. Вызывает find_failures: поскольку multiSend часто откатывает весь batch при падении любого подвызова, это самый быстрый способ увидеть, какая из 12 операций взорвалась, а не только внешний revert Safe.
  4. Вызывает get_error_path для упавшего подвызова, чтобы получить полную декодированную цепочку input/output на каждом уровне.
  5. Опционально вызывает get_call_trace_node, если какой-то важный узел был усечён.
Что вы получаете: Точный подвызов внутри batch, который упал, с декодированной целью, функцией, аргументами и причиной revert — вместо общей ошибки “GS013” Safe без контекста.

​
Post-mortem эксплойта или подозрительной транзакции

Что попросить:
“0x… в Ethereum вывел средства из нашего протокола. Проведи меня по тому, что произошло: у кого оказались деньги, что вызывал атакующий и где эксплойт зашёл в наши контракты.”
Что делает Claude:
  1. Сначала вызывает get_transaction_fund_flow — упорядоченные переводы токенов и нативных активов плюс чистый поток по каждому адресу сразу выявляют кошелёк атакующего и опустошённые адреса протокола.
  2. Вызывает get_trace_skeleton, чтобы отобразить структуру вызовов атакующего без загрузки всех аргументов.
  3. Вызывает search_call_trace для вызовов в контракты протокола (по адресу), чтобы изолировать точку входа.
  4. Вызывает get_call_trace_node в точке входа для декодированных аргументов, затем get_subtree_state_changes, чтобы увидеть, какое именно состояние мутировал эксплойт.
  5. Вызывает get_contract_info для любых неизвестных контрактов, с которыми взаимодействовал атакующий (хелперы, прокси, известные контракты эксплойтов).
Что вы получаете: Повествование эксплойта с фокусом на деньгах: кто что получил, точная функция и аргументы, спровоцировавшие вывод, и изменения состояния, которые сделали это возможным. Достаточно деталей, чтобы написать incident report или начать патч.

​
Расследование неожиданной ликвидации

Что попросить:
“Мою позицию в Aave ликвидировали в 0x…, выясни почему. Хочу знать цену оракула в момент ликвидации и точный путь health factor.”
Что делает Claude:
  1. Вызывает trace_transaction и get_trace_skeleton, чтобы отобразить дерево вызовов ликвидации.
  2. Вызывает search_call_trace для вызовов оракула (например, latestAnswer, getAssetPrice), чтобы найти чтения цены, использованные ликвидацией.
  3. Вызывает get_call_trace_node для каждого совпадения, чтобы получить декодированные возвращаемые значения — точную цену, питающую расчёт health factor.
  4. Вызывает get_transaction_fund_flow, чтобы показать, сколько collateral было изъято, сколько долга погашено и какой бонус получил ликвидатор.
  5. Опционально вызывает get_subtree_events для поддерева ликвидации — события LiquidationCall и Transfer по порядку.
Что вы получаете: Использованные цены оракулов, прибыль ликвидатора, точные суммы collateral и долга, и, если применимо, блок или транзакцию, которая уронила ваш health factor ниже 1. Полный ответ на вопрос “почему меня ликвидировали”.

​
Аудит swap через 1inch / агрегатор, который вернул меньше, чем ожидалось

Что попросить:
“0x… — это swap через 1inch, где я получил значительно меньше USDC, чем в котировке. Какой пул или hop дал плохую цену?”
Что делает Claude:
  1. Вызывает get_trace_stats — маршруты агрегатора могут быть глубокими со многими hop’ами через пулы.
  2. Вызывает get_trace_skeleton, чтобы увидеть последовательность вызовов пулов по порядку.
  3. Вызывает search_call_trace для swap, exactInput или селекторов взаимодействия с пулами роутера, вытаскивая каждый hop.
  4. Вызывает get_call_trace_node для каждого hop’а, чтобы получить декодированные значения amountIn / amountOut.
  5. Вызывает get_transaction_fund_flow, чтобы подтвердить итоговое чистое полученное и любые неожиданные переводы (комиссии, ребейты).
Что вы получаете: Разбивку входных и выходных сумм по каждому hop’у в маршруте с указанием пула, где исполнение оказалось хуже ожидаемого. Полезно для измерения slippage, сравнения маршрутов или ловли проблем с устаревшими котировками.

​
Пересимуляция упавшей транзакции с исправлением

Что попросить:
“Транзакция 0x… упала с ‘ERC20: transfer amount exceeds balance’. Пересимулируй её, но переопредели мой баланс USDC на 10 000 USDC, чтобы подтвердить, что это единственная проблема.”
Что делает Claude:
  1. Вызывает resimulate_transaction с оригинальным хешем транзакции и переопределением состояния, устанавливающим ваш баланс токена в 10 000 USDC.
  2. Если симуляция проходит, подтверждает, что корневая причина — недостаточный баланс.
  3. Вызывает get_simulation_call_trace, чтобы проверить, что путь исполнения теперь завершается без ошибки.
  4. Опционально вызывает get_simulation_asset_transfers, чтобы показать, что бы сделала транзакция, если бы прошла.
Что вы получаете: Подтверждение того, устраняет ли исправление проблему, без деплоя и трат газа. Переопределения состояния позволяют мгновенно проверять предположения — недостаточный баланс, неправильное allowance, некорректный owner — на реальном состоянии mainnet.

​
Понимание того, что сделала транзакция

Что попросить:
“Проведи меня по всему, что произошло в транзакции 0x… в Ethereum, каждый внутренний вызов, кто кого вызывал и что изменилось.”
Что делает Claude:
  1. Вызывает trace_transaction для верхнеуровневой сводки: имя метода, отправитель, получатель, использованный газ и статус.
  2. Вызывает get_simulation_call_trace, чтобы получить полное внутреннее дерево вызовов — каждый вложенный вызов с декодированными именами функций, входами, выходами и газом по каждому вызову.
  3. Вызывает get_simulation_events, чтобы перечислить все эмитированные события по порядку.
  4. Вызывает get_simulation_state_changes, чтобы показать каждый слот хранилища и баланс, которые изменились.
Что вы получаете: Полную, понятную человеку реконструкцию транзакции. Полезно для аудита незнакомых взаимодействий с протоколами, понимания MEV-активности или проверки, что сложный вызов с несколькими контрактами сделал именно то, что вы ожидали.

​
Инспекция смарт-контракта

Что попросить:
“Какой контракт задеплоен по адресу 0xdAC17F958D2ee523a2206206994597C13D831ec7 в Ethereum?”
Что делает Claude:
  1. Вызывает get_contract_info с адресом и network ID Ethereum.
Что вы получаете: Имя контракта (Tether USD), стандарты токенов (ERC-20), версию компилятора, EVM-версию, язык исходников, блок создания, адрес деплойера, хеш транзакции создания и полный ABI. Затем Claude может использовать ABI, чтобы помочь вам закодировать calldata для симуляций или собрать транзакции.

​
Отправка имперсонированной транзакции в Virtual Environment и её трассировка

Что попросить:
“В моём Virtual Environment отправь транзакцию от деплойера Uniswap V2 0x1a9C8182C09F50C8318d769245beA52c32BE35BC на контракт USDC 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, вызывающую функцию transfer, чтобы отправить 1000 USDC на мой кошелёк. Затем протрассируй исполнение.”
Что делает Claude:
  1. Вызывает send_vnet_transaction в активном Virtual Environment с деплойером как from, USDC как to и calldata transfer, закодированной по ABI. Отправитель имперсонируется, приватный ключ не нужен.
  2. Вызывает get_vnet_transactions, чтобы получить operation_id выполненной транзакции.
  3. Вызывает trace_vnet_transaction, чтобы получить декодированную сводку исполнения — имя контракта, имя функции, декодированные входные параметры и выход.
  4. Опционально вызывает get_vnet_simulation_events и get_vnet_simulation_state_changes для более глубоких деталей.
Что вы получаете: Подтверждение того, что транзакция выполнилась, декодированную трассу, показывающую успешный вызов transfer, и эмитированные события (событие Transfer с вашим кошельком в качестве получателя).

​
Тестирование многошагового взаимодействия с контрактом в Virtual Environment

Что попросить:
“В моём Virtual Environment пройди полный цикл approval и swap: сначала одобри роутер Uniswap на трату 1000 USDC с моего кошелька, затем выполни swap. Покажи мои балансы до и после.”
Что делает Claude:
  1. Вызывает send_vnet_transaction в активном Virtual Environment, чтобы отправить транзакцию approve, имперсонируя ваш кошелёк — приватный ключ не нужен.
  2. Ещё раз вызывает send_vnet_transaction с calldata swap.
  3. Вызывает get_vnet_simulation_asset_changes для каждой транзакции, чтобы показать движения токенов на каждом шаге.
  4. Вызывает get_vnet_simulation_balance_changes после последнего шага, чтобы показать чистое изменение баланса.
Что вы получаете: Пошаговое подтверждение успешности каждой транзакции, переводы токенов на каждом шаге и итоговое чистое изменение баланса. Это полный цикл тестирования до деплоя — запустите любую последовательность транзакций на форкнутом состоянии mainnet до того, как трогать реальные средства.

​
Анализ использования газа для оптимизации

Что попросить:
“Симулируй эту транзакцию и покажи разбивку газа, чтобы я мог найти самые дорогие вызовы функций: [вставьте calldata или опишите транзакцию]”
Что делает Claude:
  1. Вызывает simulate_transaction с параметрами вашей транзакции.
  2. Вызывает get_simulation_gas_breakdown, чтобы получить потребление газа по каждому вызову, включая intrinsic gas и refunds.
  3. Вызывает get_simulation_call_trace, чтобы связать стоимость газа с конкретными вызовами функций в дереве исполнения.
Что вы получаете: Ранжированный список самых газоёмких операций, привязанных к конкретным вызовам функций. Используйте это, чтобы определить, какие части логики вашего контракта стоит оптимизировать.
Используйте get_simulation_generated_access_list, чтобы сгенерировать access list EIP-2930, который может снизить стоимость газа за счёт заранее объявленных слотов хранилища и адресов, к которым обратится транзакция.

​
Форк Virtual Environment для параллельного тестирования

Что попросить:
“Форкни мой текущий Virtual Environment, чтобы я мог протестировать другой подход, не теряя текущее состояние.”
Что делает Claude:
  1. Вызывает list_vnets, чтобы найти ваш текущий Virtual Environment, затем при необходимости set_active_vnet.
  2. Вызывает fork_vnet, создавая новый Virtual Environment со всем сохранённым состоянием — задеплоенными контрактами, балансами и историей транзакций. Форк автоматически становится активным.
  3. Возвращает детали нового Virtual Environment со свежими RPC URL.
Что вы получаете: Два независимых Virtual Environment с одинаковым начальным состоянием. Вы можете тестировать разные изменения контрактов или последовательности транзакций в каждом без взаимных помех — как ветвление в git, но для состояния блокчейна.

​
Снапшот, тестирование и откат для стресс-тестирования

Что попросить:
“В моём Virtual Environment сделай снапшот текущего состояния, затем симулируй ликвидацию в Aave с разными ценами оракула. Откатывайся к снапшоту между попытками, чтобы я мог сравнить исходы.”
Что делает Claude:
  1. Вызывает snapshot_vnet, чтобы сохранить текущее состояние Virtual Environment, получая ID снапшота.
  2. Вызывает set_storage_at, чтобы переопределить цену оракула на конкретное значение.
  3. Вызывает send_vnet_transaction, чтобы запустить ликвидацию.
  4. Вызывает get_vnet_simulation_balance_changes и get_vnet_simulation_asset_changes, чтобы зафиксировать исход.
  5. Вызывает revert_vnet, чтобы восстановить Virtual Environment к состоянию снапшота (снапшот расходуется).
  6. Снова вызывает snapshot_vnet для следующей итерации, устанавливает другую цену оракула и повторяет.
Что вы получаете: Сравнение исходов ликвидации бок о бок при разных ценовых сценариях, всё тестируется на реальном форкнутом состоянии, без деплоя и влияния на другие тесты.

​
Установка балансов ERC-20 для тестирования

Что попросить:
“В моём Virtual Environment дай моему кошельку 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 баланс 10 000 USDC и 5 WETH, чтобы я мог протестировать swap.”
Что делает Claude:
  1. Вызывает set_erc20_balance с адресом токена USDC, вашим кошельком и нужным количеством.
  2. Ещё раз вызывает set_erc20_balance с адресом токена WETH и количеством.
  3. Опционально вызывает vnet_call с вызовом balanceOf, чтобы проверить, что балансы установлены корректно.
Что вы получаете: Ваш кошелёк, пополненный точными количествами токенов, готов к тестированию. Это проще, чем считать слоты хранилища вручную — set_erc20_balance автоматически учитывает раскладку хранилища токена.

​
Путешествие во времени для тестирования timelock’ов и vesting

Что попросить:
“В моём Virtual Environment продвинь часы на 7 дней вперёд, чтобы протестировать, корректно ли разблокируется мой timelock-контракт.”
Что делает Claude:
  1. Вызывает increase_time с 604800 секундами (7 дней), чтобы продвинуть часы Virtual Environment.
  2. Вызывает mine_block, чтобы зафиксировать изменение времени в новом блоке.
  3. Вызывает vnet_call, чтобы прочитать состояние timelock-контракта (например, isUnlocked() или releaseTime()).
  4. Опционально вызывает send_vnet_transaction, чтобы выполнить разблокировку и убедиться в её успехе.
Что вы получаете: Подтверждение того, разблокируется ли timelock после прыжка во времени, без ожидания 7 реальных дней. Используйте это для любой логики, зависящей от времени: расписания vesting, периодов голосования в governance, накопления процентов или окон cooldown.