> ## Documentation Index > Fetch the complete documentation index at: https://sdk.avantisfi.com/llms.txt > Use this file to discover all available pages before exploring further. # Build a transaction that claims keeper trigger rewards > For keeper bots: returns an unsigned transaction that pays out rewards accumulated by triggering limit orders and liquidations. ## OpenAPI ````yaml https://tx-builder-testnet.avantisfi.com/openapi.json post /v2/misc/claim-keeper-rewards openapi: 3.0.3 info: title: Avantis v2 API version: 2.0.0 description: >- Calldata builders, EIP-712 intent builders, signed-tx relay, and on-chain reads for the Avantis v2 perp protocol. **Conventions** - Every build/read endpoint accepts both GET (query string) and POST (JSON body) with the same fields; POST /v2/relay is POST-only. - All amounts are human units: `collateralUsdc: 100` = 100 USDC, `leverage: 10` = 10x, prices are plain USD decimals. The API does all on-chain scaling. - Responses use the `{ ok: true, data }` / `{ ok: false, error: { code, message, details } }` envelope. - Calldata responses (`to`, `from`, `data`, `value`) are unsigned — the caller signs and broadcasts (or submits via POST /v2/relay). `from` is who must sign; `value` is hex wei. - Intent responses (`domain`, `types`, `primaryType`, `message`) feed directly into EIP-712 signTypedData; the Avantis operator executes them gas-free for the signer. - Trading endpoints are rate-limited per IP. Start with GET /v2/meta (addresses, enums, units, defaults) and GET /v2/pairs (market catalog). servers: - url: https://tx-builder-testnet.avantisfi.com security: [] tags: - name: meta description: Service metadata, pair catalog, health and metrics. - name: trading description: >- Build unsigned transactions for market/limit opens and closes, margin changes, and position increases (the direct, self-broadcast route). - name: delegate description: >- Authorize or revoke a delegate key that can trade on behalf of a trader (never move funds). - name: token description: >- USDC approval transactions — the one-time prerequisite before trading or LP deposits. - name: intents description: >- Build EIP-712 typed-data payloads to sign; the Avantis operator submits them on-chain so the signer pays no gas (the relayer route). - name: relay description: >- Submit an already-signed transaction through Avantis-operated RPCs: whitelist check, simulation with decoded revert reasons, then broadcast. - name: twap description: >- Time-weighted orders, filled in slices by the operator over a chosen duration. - name: referral description: >- Referral code registration, assignment, ownership transfer, and rebate claims. - name: lp description: >- Liquidity-provider flows on the Avantis USDC vault (ERC-4626 avUSDC tranche). - name: misc description: Keeper reward claims, vault buffer top-ups, and builder-code registration. - name: reads description: >- On-chain lookups the SDK needs for signing correctness: nonces, positions, delegation state, allowances. paths: /v2/misc/claim-keeper-rewards: post: tags: - misc summary: Build a transaction that claims keeper trigger rewards description: >- For keeper bots: returns an unsigned transaction that pays out rewards accumulated by triggering limit orders and liquidations. operationId: postV2MiscClaimKeeperRewards requestBody: required: true content: application/json: schema: type: object properties: caller: type: string description: The account sending this transaction (must sign it). required: - caller additionalProperties: false responses: '200': description: >- Success envelope: `ok` is `true` and `data` carries the payload documented below. content: application/json: schema: type: object required: - ok - data properties: ok: type: boolean enum: - true description: Always `true` on success. data: type: object description: >- An unsigned EVM transaction. Sign it with the `from` key and broadcast it yourself, or submit the signed bytes via POST /v2/relay. properties: to: type: string description: >- Contract to call (already resolved, e.g. the TradingRouter proxy). example: '0x0000000000000000000000000000000000000000' from: type: string description: >- The account that must sign and send this transaction — the trader, or the delegate when the call is wrapped in `delegatedAction`. example: '0x0000000000000000000000000000000000000000' data: type: string description: ABI-encoded calldata, 0x-prefixed hex. value: type: string description: >- Required `msg.value` in wei as 0x-prefixed hex (hex avoids JSON precision loss on big values). Non-zero when an operator execution fee must be attached — forward it verbatim. example: '0x0' chainId: type: integer description: Chain the transaction is valid on (EIP-155). description: type: string description: Human-readable summary of what this transaction does. meta: type: object description: >- Echo of the resolved request parameters. Informational only — not part of the transaction. properties: {} additionalProperties: true required: - to - from - data - value - chainId - description '400': description: >- Invalid input (failed schema validation or pre-trade checks like liquidity, leverage bounds, min position size, or market hours). content: application/json: schema: type: object required: - ok - error properties: ok: type: boolean enum: - false description: Always `false` on errors. error: type: object required: - code - message description: Machine-readable error. properties: code: type: string enum: - BAD_REQUEST description: Stable error code for programmatic handling. message: type: string description: Human-readable explanation of what went wrong. details: description: >- Optional structured context — e.g. Zod validation issues on BAD_REQUEST, or `{ target, revertData, decodedError }` on SIMULATION_FAILED. ````