## Analyzing a Transaction to Claim Funding Fees This lesson guides you through analyzing a specific blockchain transaction to understand the process for programmatically claiming funding fees. By examining the transaction details using tools like Tenderly and Arbiscan, we can identify the target smart contract, the function called, and the necessary input parameters required to replicate the action. We begin by inspecting the transaction summary in Tenderly. The "Tokens transferred" section reveals the net result of the operation. In the analyzed transaction, we observe the following transfers, indicating the claimed fees: * From `MarketToken` to `0xd24cba...40f49e`: ≈ 0 WETH (ERC-20) * From `MarketToken` to `0xd24cba...40f49e`: 0.124 USDC (ERC-20) * From `MarketToken` to `0xd24cba...40f49e`: ≈ 0 WETH (ERC-20) The recipient address (`0xd24cba...40f49e`) is the account that initiated the transaction and received the fees. To understand *how* these fees were claimed, we examine the transaction's execution trace, often found at the bottom of the Tenderly overview or within its dedicated trace/debugger views. This trace reveals the sequence of contract interactions. The key interaction for our purpose involves a call to the: * **Contract:** `ExchangeRouter` * **Function:** `claimFundingFees` This tells us the specific contract and function we need to interact with to programmatically claim funding fees within this protocol. Next, we dive deeper using the Tenderly "Debugger" tab to inspect the exact inputs provided to the `claimFundingFees` function call. This reveals the parameters required: * **`markets` (Array of Addresses):** Specifies the market contracts from which fees are being claimed. In this transaction, the input was: ``` [ "0x70d95587d40a2caf56bd97485ab3eec10bee6336", "0x70d95587d40a2caf56bd97485ab3eec10bee6336", "0x450bb6774dd8a756274e0ab4107953259d2ac541" ] ``` * **`tokens` (Array of Addresses):** Specifies the corresponding token addresses for the fees being claimed in each respective market. The input was: ``` [ "0x82af49447d8a07e3bd95bd0d56f35241523fbab1", "0xaf88d065e77c8cC2239327C5EDb3A432268e5831", "0x82af49447d8a07e3bd95bd0d56f35241523fbab1" ] ``` * **`receiver` (Address):** The address designated to receive the claimed fees. The input was: ``` "0xd24cba75f7af6081bff9e6122f4054f32140f49e" ``` This matches the recipient observed in the token transfers, confirming it's the caller's address. The `tokens` array contains contract addresses. To understand which actual tokens these represent, we use a block explorer compatible with the network (Arbiscan for Arbitrum in this case). Looking up these addresses reveals: * `0x82af49447d8a07e3bd95bd0d56f35241523fbab1` corresponds to **Wrapped Ether (WETH)**. * `0xaf88d065e77c8cC2239327C5EDb3A432268e5831` corresponds to **USD Coin (USDC)**. With the tokens identified, we can map the inputs. The `markets` and `tokens` arrays are parallel; the function attempts to claim the token at `tokens[i]` from the market at `markets[i]`. For this specific transaction, the claims were structured as: 1. Claim WETH from market `0x70d9...6336` 2. Claim USDC from market `0x70d9...6336` 3. Claim WETH from market `0x450b...c541` This analysis highlights several core web3 concepts: * **Smart Contract Interaction:** Performing actions like claiming fees involves calling functions on deployed smart contracts. * **Function Calls & Parameters:** The specific action (`claimFundingFees`) and its details are defined by the function called and the inputs (`markets`, `tokens`, `receiver`) provided. * **Transaction Analysis:** Tools like Tenderly allow dissection of past transactions to understand execution flow and parameters, crucial for debugging or replication. * **Token Addresses:** ERC-20 tokens are represented by unique contract addresses, identifiable using block explorers like Arbiscan. In conclusion, by analyzing this transaction using Tenderly and Arbiscan, we determined that programmatically claiming funding fees via this protocol requires calling the `claimFundingFees` function on the `ExchangeRouter` contract. This call must include arrays specifying the markets and corresponding token addresses for the fees being claimed, along with the address designated to receive the fees. Remember that the specific market and token addresses identified here pertain only to this example transaction; you must determine the correct addresses relevant to the fees *you* intend to claim.