> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tenderly.co/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Server उदाहरण

> Claude के साथ Tenderly MCP Server का उपयोग करते हुए सामान्य workflows के लिए चरण-दर-चरण walkthroughs।

ये walkthroughs दिखाते हैं कि Claude वास्तविक विकास कार्यों को पूरा करने के लिए [Tenderly MCP Server](/ai-tools/overview) टूल्स का उपयोग कैसे करता है। यदि आपने अभी तक इसे कनेक्ट नहीं किया है, तो पहले [MCP Server quickstart](/ai-tools/quickstart) का पालन करें। आपको नाम से टूल्स को call करने की आवश्यकता नहीं है, बस बताएँ कि आप क्या चाहते हैं और Claude बाकी संभालता है।

उदाहरण मोटे तौर पर गतिविधि के अनुसार समूहीकृत हैं:

* **Setup और pre-flight**: परिवेश शुरू करना, wallets fund करना, हस्ताक्षर करने से पहले transactions की जाँच करना।
* **Debugging और post-mortem**: यह पता लगाना कि एक transaction क्यों विफल हुआ, किसने funds लिए, या एक swap ने अपेक्षा से कम क्यों लौटाया। advanced trace navigation टूल्स यहाँ चमकते हैं।
* **Virtual Environment workflows**: impersonation, बहु-चरणीय परीक्षण, snapshots, time-travel, token balance overrides।
* **Optimization और inspection**: gas breakdowns, contract metadata।

## एक Virtual Environment बनाएँ और एक wallet fund करें

**क्या पूछें:**

> "Ethereum mainnet से forked एक Virtual Environment बनाएँ और मेरे wallet 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 को 100 ETH से fund करें।"

**Claude क्या करता है:**

1. आपके projects खोजने के लिए `list_projects` call करता है, फिर एक चुनने के लिए `set_active_project`।
2. Ethereum mainnet network ID खोजने के लिए `get_networks` call करता है।
3. एक forked परिवेश बनाते हुए network ID के साथ `create_vnet` call करता है। नया Virtual Environment स्वचालित रूप से active सेट हो जाता है।
4. आपके wallet address के साथ `fund_account` call करता है, balance को hex wei में 100 ETH पर सेट करता है। स्वचालित रूप से active Virtual Environment पर काम करता है।
5. Hardhat, Foundry, या किसी भी Web3 library में उपयोग के लिए तैयार **Admin RPC** और **Public RPC** URLs सहित Virtual Environment विवरण लौटाता है।

**आपको क्या वापस मिलता है:**

नवीनतम mainnet state से forked एक चलता हुआ Virtual Environment, आपका wallet funded, और RPC URLs जिन्हें आप अपने विकास framework config में डाल सकते हैं।

***

## Uniswap swap को simulate करें

**क्या पूछें:**

> "Ethereum mainnet पर 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 से Uniswap V3 पर 1 ETH का USDC के लिए swap simulate करें। मुझे अपेक्षित output और कोई भी token transfers दिखाएँ।"

**Claude क्या करता है:**

1. Uniswap V3 router address, आपके sender address, swap calldata, और value के रूप में 1 ETH के साथ `simulate_transaction` call करता है।
2. simulation वर्तमान mainnet state के विरुद्ध चलता है और लौटाता है: success/revert status, gas used, और decoded method नाम।
3. सभी token movements, ETH अंदर जाता और USDC बाहर आता, दिखाने के लिए `get_simulation_asset_transfers` call करता है।
4. USD values के साथ आपके balances पर शुद्ध प्रभाव दिखाने के लिए `get_simulation_balance_changes` call करता है।

**आपको क्या वापस मिलता है:**

सटीक USDC output, gas cost, और हर asset transfer का breakdown। यदि swap revert होगा (जैसे, slippage बहुत अधिक), तो आपको decoded revert reason मिलेगा।

***

## भेजने से पहले एक transaction का pre-flight check

**क्या पूछें:**

> "मैं 0xE592427A0AEce92De3Edee1F18E0157C05861564 को असीमित USDC allowance देने के लिए 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 पर `approve` call करने वाला हूँ। पहले इसे simulate करें और मुझे दिखाएँ कि यह कौन सी approvals और state changes बनाएगा।"

**Claude क्या करता है:**

1. आपके wallet को sender के रूप में, token contract को recipient के रूप में, और `approve` calldata के साथ `simulate_transaction` call करता है।
2. हर approval और allowance change दिखाने के लिए `get_simulation_exposure_changes` call करता है, कौन सा spender किसको access पाता है और कितना।
3. संशोधित सटीक storage slots दिखाने के लिए `get_simulation_state_changes` call करता है।

**आपको क्या वापस मिलता है:**

दी जा रही सटीक approval (spender address, token, amount), storage diff जो पुष्टि करती है कि allowance slot बदला है, और क्या transaction सफल होगा। किसी भी समय उपयोगी जब आप एक अपरिचित contract के साथ interact कर रहे हों या हस्ताक्षर करने से पहले calldata सत्यापित करना चाहते हों।

***

## एक विफल on-chain transaction को debug करें

**क्या पूछें:**

> "transaction 0x6c5df5a1e6b34e2432ae19706e38a84239495cdbf40c2a9d4d79806443c4aa0d Ethereum पर क्यों revert हुआ?"

**Claude क्या करता है:**

1. tx hash के साथ `trace_transaction` call करता है। status (`false` = reverted), gas used, decoded method नाम, और error संदेश लौटाता है।
2. पूर्ण internal call tree प्राप्त करने के लिए `get_simulation_call_trace` call करता है, decoded names, inputs, outputs, और कौन सी विशिष्ट call विफल हुई इसके साथ हर function call।
3. revert point से पहले कौन से events emit किए गए यह देखने के लिए `get_simulation_events` call करता है।
4. वैकल्पिक रूप से यह देखने के लिए `get_simulation_state_changes` call करता है कि विफलता तक कौन सी state संशोधित की गई थी।

**आपको क्या वापस मिलता है:**

एक स्पष्ट स्पष्टीकरण कि कौन सी internal call विफल हुई, decoded revert reason (जैसे, `"ERC20: transfer amount exceeds balance"`), और पूर्ण call trace ताकि आप विफलता तक ले जाने वाले execution रास्ते को देख सकें।

***

## गहराई से nested transaction में revert का मूल कारण खोजें

**क्या पूछें:**

> "Transaction 0x... Ethereum पर revert हुआ। यह बहुत सारे internal calls वाला एक जटिल DeFi call है, वास्तविक error खोजें और मुझे उस रास्ते को दिखाएँ जो इसकी ओर ले गया।"

**Claude क्या करता है:**

1. top-level सारांश के लिए `trace_transaction` call करता है और revert की पुष्टि करता है।
2. transaction में हर failing call सूचीबद्ध करने के लिए `find_failures` call करता है, केवल सबसे बाहरी नहीं। यह मूल revert और कोई भी wrapping `require`/try-catch failures दोनों सामने लाता है।
3. प्रत्येक स्तर पर decoded inputs और outputs के साथ root call से गहनतम failing call तक blame chain लौटाने के लिए `get_error_path` call करता है।
4. यदि किसी node में अभी भी omitted children हैं, तो इसे विस्तारित करने के लिए विशिष्ट position पर `get_call_trace_node` call करता है।

**आपको क्या वापस मिलता है:**

गहनतम विफलता पर सटीक contract, function, और decoded revert reason, साथ ही वहाँ ले जाने वाले callers की पूर्ण chain। 200-call `get_simulation_call_trace` output से paging करने की तुलना में बहुत तेज़।

***

## एक बहुत बड़े trace को नेविगेट करें

**क्या पूछें:**

> "इस transaction में सैकड़ों internal calls हैं और `get_simulation_call_trace` truncated है। इसकी संरचना समझने में मेरी मदद करें और उस भाग में drill करें जो मायने रखता है।"

**Claude क्या करता है:**

1. कुल calls, अधिकतम गहराई, error count, और अद्वितीय contracts report करने के लिए `get_trace_stats` call करता है, एक त्वरित size check जो रणनीति तय करता है।
2. एक compressed call tree प्राप्त करने के लिए `get_trace_skeleton` call करता है: प्रति node function नाम, contract, depth, और error flag, बिना decoded args के।
3. skeleton से `absolute_position` values का उपयोग करके दिलचस्प subtree (एक failing branch, एक विशिष्ट protocol, या एक संदिग्ध contract) की पहचान करता है।
4. उस subtree को पूर्ण decoded inputs और outputs के साथ विस्तारित करने के लिए `get_call_trace_node` call करता है।
5. वैकल्पिक रूप से केवल उस subtree से events और storage diffs देखने के लिए `get_subtree_events` और `get_subtree_state_changes` call करता है।

**आपको क्या वापस मिलता है:**

transaction की संरचना का एक map, फिर बस उस भाग पर पूर्ण विवरण जिसकी आप परवाह करते हैं, बिना हजारों calls को context में लोड किए।

***

## एक विशिष्ट contract या function के लिए एक trace खोजें

**क्या पूछें:**

> "क्या इस transaction ने कभी USDC पर `transferFrom` call किया? यदि हाँ, तो मुझे decoded args के साथ हर call दिखाएँ।"

**Claude क्या करता है:**

1. USDC address और `transferFrom` को filters के रूप में `search_call_trace` call करता है, केवल matching calls को उनके decoded inputs, outputs, और absolute positions के साथ लौटाता है।
2. किसी भी match के लिए जो दिलचस्प है, उसके चारों ओर पूर्ण nested context लाने के लिए `get_call_trace_node` call करता है।

**आपको क्या वापस मिलता है:**

पूर्ण trace के बजाय matching calls की एक targeted सूची। बड़े transactions पर "क्या X हुआ" प्रश्नों का उत्तर देने के लिए, और यह audit करने के लिए कि क्या एक known-risky selector invoke किया गया था।

***

## एक transaction के माध्यम से पैसे का पालन करें

**क्या पूछें:**

> "Ethereum पर transaction 0x... के लिए, मुझे दिखाएँ कि किसने किसको क्या भेजा, क्रम में, USD values के साथ।"

**Claude क्या करता है:**

1. tx hash के साथ `get_transaction_fund_flow` call करता है। ordered token और native transfers लौटाता है, प्रत्येक from/to addresses और USD values के साथ, साथ ही प्रति address एक शुद्ध flow।
2. वैकल्पिक रूप से किसी भी अपरिचित address पर उसे पहचानने के लिए `get_contract_info` call करता है (protocol router, pool, treasury, आदि)।

**आपको क्या वापस मिलता है:**

transaction का एक chronological money map और प्रति-address शुद्ध flow, MEV bundles, अपरिचित DeFi interactions को समझने के लिए, या यह सत्यापित करने के लिए कि एक multi-hop swap ने funds को अपेक्षित रूप से स्थानांतरित किया, आदर्श। केवल On-chain transactions।

***

## एक विफल Safe multisig batch execution को debug करें

**क्या पूछें:**

> "0x... पर हमारा Safe batch execution Ethereum पर revert हुआ। batch में 12 calls हैं। कौन सा वास्तव में विफल हुआ और क्यों?"

**Claude क्या करता है:**

1. revert की पुष्टि करने और top-level method (`execTransaction` या `multiSend`) प्राप्त करने के लिए `trace_transaction` call करता है।
2. `get_trace_stats` call करता है, Safe batches जल्दी से बड़े traces में विस्फोट होते हैं, इसलिए stats अगले step का निर्णय लेता है।
3. `find_failures` call करता है, क्योंकि `multiSend` अक्सर किसी भी sub-call विफलता पर पूरे batch को revert करता है, यह देखने का सबसे तेज़ तरीका है कि 12 operations में से कौन सा विस्फोट हुआ, न कि केवल बाहरी Safe revert।
4. प्रत्येक स्तर पर पूर्ण decoded input/output chain के लिए failing sub-call पर `get_error_path` call करता है।
5. यदि कोई प्रासंगिक node truncated था तो वैकल्पिक रूप से `get_call_trace_node` call करता है।

**आपको क्या वापस मिलता है:**

batch के अंदर विफल हुई सटीक sub-call, decoded target, function, arguments, और revert reason के साथ, बिना context के एक generic "GS013" Safe error के बजाय।

***

## एक exploit या संदिग्ध transaction का post-mortem

**क्या पूछें:**

> "Ethereum पर 0x... ने हमारे protocol से funds drain किए। मुझे बताएँ कि क्या हुआ: पैसा किसके पास पहुँचा, attacker ने क्या call किया, और exploit हमारे contracts में कहाँ प्रवेश किया।"

**Claude क्या करता है:**

1. पहले `get_transaction_fund_flow` call करता है, ordered token और native flows साथ ही प्रति-address शुद्ध flow तुरंत attacker का wallet और drained protocol addresses सामने लाते हैं।
2. हर argument लोड किए बिना attacker की call संरचना का map बनाने के लिए `get_trace_skeleton` call करता है।
3. entry point को अलग करने के लिए protocol के contracts में calls के लिए (address द्वारा) `search_call_trace` call करता है।
4. decoded args के लिए entry point पर `get_call_trace_node` call करता है, फिर यह देखने के लिए `get_subtree_state_changes` कि exploit ने वास्तव में कौन सी state mutate की।
5. attacker ने जिन किसी भी अज्ञात contracts के साथ interact किया उन पर `get_contract_info` call करता है (helpers, proxies, known exploit contracts)।

**आपको क्या वापस मिलता है:**

exploit का एक money-first कथन: किसे क्या मिला, drain को ट्रिगर करने वाला सटीक function और arguments, और वे state changes जिन्होंने इसे संभव बनाया। एक incident report लिखने या एक patch शुरू करने के लिए पर्याप्त विवरण।

***

## एक अप्रत्याशित liquidation की जाँच करें

**क्या पूछें:**

> "मेरी Aave position 0x... में liquidate हो गई, पता लगाएँ क्यों। मैं liquidation समय पर oracle price और सटीक health-factor path जानना चाहता हूँ।"

**Claude क्या करता है:**

1. liquidation call tree का map बनाने के लिए `trace_transaction` और `get_trace_skeleton` call करता है।
2. liquidation ने जिन price reads का उपयोग किया, उन्हें खोजने के लिए oracle calls (जैसे, `latestAnswer`, `getAssetPrice`) के लिए `search_call_trace` call करता है।
3. decoded return values के लिए प्रत्येक match पर `get_call_trace_node` call करता है, health-factor math को feed करने वाली सटीक price।
4. यह दिखाने के लिए `get_transaction_fund_flow` call करता है कि कितना collateral seize किया गया, कर्ज़ चुकाया गया, और liquidator का bonus।
5. वैकल्पिक रूप से क्रम में `LiquidationCall` और `Transfer` events के लिए liquidation subtree पर `get_subtree_events` call करता है।

**आपको क्या वापस मिलता है:**

उपयोग की गई oracle prices, liquidator का लाभ, सटीक collateral और debt amounts, और, यदि लागू हो, वह block या transaction जिसने आपके health factor को 1 से नीचे ले जाया। एक पूर्ण "मैं क्यों liquidate हुआ" उत्तर।

***

## एक 1inch / aggregator swap को audit करें जिसने अपेक्षा से कम लौटाया

**क्या पूछें:**

> "0x... एक 1inch swap था जहाँ मुझे quote से काफी कम USDC मिला। किस pool या hop ने bad price दिया?"

**Claude क्या करता है:**

1. `get_trace_stats` call करता है, aggregator routes कई pool hops के साथ गहरे हो सकते हैं।
2. क्रम में pool calls का अनुक्रम देखने के लिए `get_trace_skeleton` call करता है।
3. `swap`, `exactInput`, या router के pool-interaction selectors के लिए `search_call_trace` call करता है, प्रत्येक hop को खींचता है।
4. decoded `amountIn` / `amountOut` values के लिए प्रत्येक hop पर `get_call_trace_node` call करता है।
5. अंतिम शुद्ध प्राप्त और किसी भी अप्रत्याशित transfers (fees, rebates) की पुष्टि करने के लिए `get_transaction_fund_flow` call करता है।

**आपको क्या वापस मिलता है:**

route के पार input और output amounts का एक per-hop breakdown, उस pool को call out किया गया जिसका execution अपेक्षा से खराब था। slippage मापने, routes की तुलना करने, या stale-quote issues पकड़ने के लिए उपयोगी।

***

## एक विफल transaction को fix के साथ फिर से simulate करें

**क्या पूछें:**

> "Transaction 0x... 'ERC20: transfer amount exceeds balance' के साथ विफल हुआ। इसे फिर से simulate करें लेकिन यह पुष्टि करने के लिए मेरे USDC balance को 10,000 USDC पर override करें कि यही एकमात्र issue है।"

**Claude क्या करता है:**

1. मूल tx hash और आपके token balance को 10,000 USDC पर सेट करने वाले एक state override के साथ `resimulate_transaction` call करता है।
2. यदि simulation सफल होता है, तो पुष्टि करता है कि root cause अपर्याप्त balance था।
3. यह सत्यापित करने के लिए `get_simulation_call_trace` call करता है कि execution path अब बिना error के पूरा होता है।
4. वैकल्पिक रूप से यह दिखाने के लिए `get_simulation_asset_transfers` call करता है कि यदि transaction सफल हुआ होता तो क्या किया होता।

**आपको क्या वापस मिलता है:**

पुष्टि कि क्या fix issue हल करता है, कुछ भी deploy किए बिना या gas खर्च किए बिना। State overrides आपको धारणाओं का परीक्षण करने देते हैं, अपर्याप्त balance, गलत allowance, गलत ownership, तुरंत, वास्तविक mainnet state के विरुद्ध।

***

## समझें कि एक transaction ने क्या किया

**क्या पूछें:**

> "मुझे बताएँ कि Ethereum पर transaction 0x... में क्या हुआ, हर internal call, किसने किसे call किया, और क्या बदला।"

**Claude क्या करता है:**

1. एक top-level सारांश के लिए `trace_transaction` call करता है: method नाम, sender, recipient, gas used, और status।
2. पूर्ण internal call tree प्राप्त करने के लिए `get_simulation_call_trace` call करता है, decoded function names, inputs, outputs, और प्रति-call gas के साथ हर nested call।
3. क्रम में emit किए गए सभी events सूचीबद्ध करने के लिए `get_simulation_events` call करता है।
4. बदले हुए हर storage slot और balance दिखाने के लिए `get_simulation_state_changes` call करता है।

**आपको क्या वापस मिलता है:**

transaction का एक पूर्ण, मानव-पठनीय पुनर्निर्माण। अपरिचित protocol interactions को audit करने, MEV गतिविधि को समझने, या यह सत्यापित करने के लिए उपयोगी कि एक जटिल multi-contract call ने वास्तव में वही किया जो आपने अपेक्षा की थी।

***

## एक smart contract का निरीक्षण करें

**क्या पूछें:**

> "Ethereum पर 0xdAC17F958D2ee523a2206206994597C13D831ec7 पर कौन सा contract deploy है?"

**Claude क्या करता है:**

1. address और Ethereum के network ID के साथ `get_contract_info` call करता है।

**आपको क्या वापस मिलता है:**

contract नाम (Tether USD), token standards (ERC-20), compiler version, EVM version, source भाषा, creation block, deployer address, creation transaction hash, और पूर्ण ABI। Claude फिर आपको simulations के लिए calldata encode करने या transactions बनाने में मदद करने के लिए ABI का उपयोग कर सकता है।

***

## एक Virtual Environment पर एक impersonated transaction भेजें और उसे trace करें

**क्या पूछें:**

> "मेरे Virtual Environment पर, Uniswap V2 deployer 0x1a9C8182C09F50C8318d769245beA52c32BE35BC से USDC contract 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 पर `transfer` function को call करते हुए मेरे wallet को 1000 USDC भेजने के लिए एक transaction भेजें। फिर execution को trace करें।"

**Claude क्या करता है:**

1. deployer को `from` के रूप में, USDC को `to` के रूप में, और ABI-encoded `transfer` calldata के साथ active Virtual Environment पर `send_vnet_transaction` call करता है। sender impersonate किया जाता है, कोई निजी key की आवश्यकता नहीं।
2. execute किए गए transaction का `operation_id` प्राप्त करने के लिए `get_vnet_transactions` call करता है।
3. decoded execution सारांश प्राप्त करने के लिए `trace_vnet_transaction` call करता है, contract नाम, function नाम, decoded input parameters, और output।
4. गहरे विवरण के लिए वैकल्पिक रूप से `get_vnet_simulation_events` और `get_vnet_simulation_state_changes` call करता है।

**आपको क्या वापस मिलता है:**

पुष्टि कि transaction execute हुआ, decoded trace जो दिखाता है कि `transfer` call सफल हुआ, और emit किए गए events (आपके wallet को recipient के रूप में Transfer event)।

***

## एक Virtual Environment पर एक multi-step contract interaction का परीक्षण करें

**क्या पूछें:**

> "मेरे Virtual Environment पर, पूरा approval और swap flow चलाएँ: पहले Uniswap router को मेरे wallet से 1000 USDC खर्च करने की approve करें, फिर swap execute करें। मुझे पहले और बाद में मेरे balances दिखाएँ।"

**Claude क्या करता है:**

1. `approve` transaction submit करने के लिए active Virtual Environment पर `send_vnet_transaction` call करता है, आपके wallet को impersonate करते हुए, कोई निजी key की आवश्यकता नहीं।
2. swap calldata के साथ फिर से `send_vnet_transaction` call करता है।
3. प्रति step token movements दिखाने के लिए प्रत्येक transaction पर `get_vnet_simulation_asset_changes` call करता है।
4. शुद्ध balance प्रभाव दिखाने के लिए अंतिम step के बाद `get_vnet_simulation_balance_changes` call करता है।

**आपको क्या वापस मिलता है:**

चरण-दर-चरण पुष्टि कि प्रत्येक transaction सफल हुआ, प्रति step token transfers, और आपका अंतिम शुद्ध balance परिवर्तन। यह पूर्ण pre-deployment testing loop है, वास्तविक funds को छूने से पहले एक forked mainnet state के विरुद्ध transactions का कोई भी अनुक्रम चलाएँ।

***

## optimization के लिए gas उपयोग का विश्लेषण करें

**क्या पूछें:**

> "इस transaction को simulate करें और मुझे एक gas breakdown दिखाएँ ताकि मैं सबसे महँगे function calls खोज सकूँ: \[calldata paste करें या transaction का वर्णन करें]"

**Claude क्या करता है:**

1. आपके transaction parameters के साथ `simulate_transaction` call करता है।
2. intrinsic gas और refunds सहित प्रति-call gas खपत प्राप्त करने के लिए `get_simulation_gas_breakdown` call करता है।
3. execution tree में विशिष्ट function calls पर gas costs map करने के लिए `get_simulation_call_trace` call करता है।

**आपको क्या वापस मिलता है:**

सबसे gas-महँगे operations की एक ranked सूची, विशिष्ट function calls पर mapped। इसका उपयोग यह पहचानने के लिए करें कि अपने contract logic के कौन से भागों को optimize करना है।

<Note>
  एक EIP-2930 access list उत्पन्न करने के लिए `get_simulation_generated_access_list` का उपयोग करें, जो पहले से घोषित करके gas costs को कम कर सकता है कि transaction कौन से storage slots और addresses access करेगा।
</Note>

***

## समानांतर परीक्षण के लिए एक Virtual Environment को fork करें

**क्या पूछें:**

> "मेरे वर्तमान Virtual Environment को fork करें ताकि मैं वर्तमान state खोए बिना एक अलग approach test कर सकूँ।"

**Claude क्या करता है:**

1. आपका वर्तमान Virtual Environment खोजने के लिए `list_vnets` call करता है, फिर यदि आवश्यक हो तो `set_active_vnet`।
2. `fork_vnet` call करता है, deployed contracts, balances, और transaction history सहित सभी state संरक्षित करते हुए एक नया Virtual Environment बनाता है। fork स्वचालित रूप से active सेट हो जाता है।
3. ताज़ा RPC URLs के साथ नए Virtual Environment विवरण लौटाता है।

**आपको क्या वापस मिलता है:**

एक ही शुरुआती state साझा करने वाले दो स्वतंत्र Virtual Environments। आप हस्तक्षेप के बिना प्रत्येक में विभिन्न contract changes या transaction sequences का परीक्षण कर सकते हैं, git में branching की तरह, लेकिन blockchain state के लिए।

***

## stress-testing के लिए snapshot, test, और revert

**क्या पूछें:**

> "मेरे Virtual Environment पर, वर्तमान state का snapshot लें, फिर विभिन्न oracle prices के साथ Aave पर एक liquidation simulate करें। प्रत्येक प्रयास के बीच snapshot पर revert करें ताकि मैं परिणामों की तुलना कर सकूँ।"

**Claude क्या करता है:**

1. एक snapshot ID प्राप्त करते हुए वर्तमान Virtual Environment state save करने के लिए `snapshot_vnet` call करता है।
2. oracle price को एक विशिष्ट value पर override करने के लिए `set_storage_at` call करता है।
3. liquidation ट्रिगर करने के लिए `send_vnet_transaction` call करता है।
4. परिणाम capture करने के लिए `get_vnet_simulation_balance_changes` और `get_vnet_simulation_asset_changes` call करता है।
5. snapshot state पर Virtual Environment को restore करने के लिए `revert_vnet` call करता है (snapshot consume हो जाता है)।
6. अगले iteration के लिए फिर से `snapshot_vnet` call करता है, एक अलग oracle price सेट करता है, और दोहराता है।

**आपको क्या वापस मिलता है:**

विभिन्न price scenarios के तहत liquidation परिणामों की एक side-by-side तुलना, सभी वास्तविक forked state के विरुद्ध परीक्षण, बिना कुछ deploy किए या अन्य परीक्षणों को प्रभावित किए।

***

## परीक्षण के लिए ERC-20 balances सेट करें

**क्या पूछें:**

> "मेरे Virtual Environment पर, मेरे wallet 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 को 10,000 USDC और 5 WETH का balance दें ताकि मैं एक swap test कर सकूँ।"

**Claude क्या करता है:**

1. USDC token address, आपके wallet, और वांछित amount के साथ `set_erc20_balance` call करता है।
2. WETH token address और amount के साथ फिर से `set_erc20_balance` call करता है।
3. वैकल्पिक रूप से balances सही ढंग से सेट हुए हैं यह सत्यापित करने के लिए `balanceOf` call के साथ `vnet_call` call करता है।

**आपको क्या वापस मिलता है:**

सटीक token amounts के साथ funded आपका wallet, परीक्षण के लिए तैयार। यह storage slots की मैन्युअल गणना करने से सरल है, `set_erc20_balance` token के storage layout को स्वचालित रूप से संभालता है।

***

## timelocks और vesting का परीक्षण करने के लिए time-travel

**क्या पूछें:**

> "मेरे Virtual Environment पर, यह जाँचने के लिए घड़ी को 7 दिन आगे बढ़ाएँ कि क्या मेरा timelock contract सही ढंग से unlock होता है।"

**Claude क्या करता है:**

1. Virtual Environment घड़ी को आगे बढ़ाने के लिए 604800 सेकंड (7 दिन) के साथ `increase_time` call करता है।
2. time change को एक नए block में commit करने के लिए `mine_block` call करता है।
3. timelock contract की state पढ़ने के लिए `vnet_call` call करता है (जैसे, `isUnlocked()` या `releaseTime()`)।
4. वैकल्पिक रूप से unlock execute करने और यह सत्यापित करने के लिए `send_vnet_transaction` call करता है कि यह सफल होता है।

**आपको क्या वापस मिलता है:**

पुष्टि कि क्या time skip के बाद timelock unlockable है, 7 वास्तविक दिनों की प्रतीक्षा किए बिना। किसी भी time-निर्भर logic के लिए इसका उपयोग करें: vesting schedules, governance voting अवधि, interest accrual, या cooldown windows।