Aave

View saved version →

---
name: account-activity
description: An Aave account's history — past supplies, borrows, repays, withdrawals and collateral changes, and how net worth or health factor moved over time — for "transaction history", "how has my position changed", what a wallet did on Aave.
---

# Aave account activity

## Steps

1. `get_user_activity` for the event feed, most recent first. v4 covers every chain in one read; v3 reads one market on one chain at a time and states that scope — so on v3, sweep the markets the wallet actually holds (from `get_user_positions`) rather than treating one market's page as the full history.
2. Position trajectory: `get_user_summary_history` (v4) for net worth, debt and health factor over a window — the "how close to liquidation have I been" question.
3. Paging: pass `pageInfo.next` back as `cursor` with an explicit version — a cursor belongs to one version's feed.

## Reporting rules

- State the scope of any v3 history answer (which market, which chain); never present one market's page as the wallet's complete history.
- "Where does this wallet hold anything" is `get_user_positions`, not this feed.

## Done when

- On v3, every market the wallet holds was swept, and the answer names the markets and chains it covers.
- The answer says whether the feed was read to its end or stopped at a page, so a partial history reads as partial.

View saved version →

---
name: deleverage
description: Reduce the risk on an Aave position — "reduce my risk", "unwind", "get my health factor up", "I'm close to liquidation" — by comparing the routes (repay, repay from collateral, add collateral) on the resulting health factor before recommending one.
---

# Aave deleveraging

There are three ways to lift a health factor, and they cost the user different things. Compare them before recommending one.

## Steps

1. **Inspect** — `get_user_summary` for the health factor, then `get_user_positions` for the debt and collateral by asset. Identify the largest debt and the collateral with the highest liquidation threshold.
2. **Route A: repay from wallet** — `get_markets` with `user` for the debt asset's wallet balance. If the wallet holds it, `preview_action` (action `repay`) at the amount that reaches the target health factor.
3. **Route B: repay from collateral** — on v4, `get_repay_with_supply_quote` for the debt against the collateral; it is atomic and the health factor never passes through a worse state. On v3 there is no atomic route: a withdraw → repay sequence dips the health factor between steps, and that must be said.
4. **Route C: add collateral** — `preview_action` (action `supply`, `enableCollateral: true`) for an asset the wallet holds.
5. **Compare** — one table: route, what the user gives up, health factor after, and what remains at risk. Recommend the route that reaches the target with the least the user must part with, and say why the others rank lower.

## Rules

- Default target health factor is **1.5** unless the user names one. Below 1.1 is urgent: say so first, then compare routes.
- Every simulated route reports its `healthFactorAfter`; a route that cannot be simulated is described as unsimulated, not estimated.
- Build nothing until the user picks a route; then hand over to the `safe-transactions` skill for the build.

## Done when

- Every route the position allows was simulated or quoted, with the health factor after.
- The answer says which route reaches the target with the least given up, and why.
- If the position is on v3, the answer says there is no atomic repay-from-collateral and names the health-factor dip.

View saved version →

---
name: safe-transactions
description: Prepare an Aave state change — supply, borrow, withdraw, repay, or any other prepare_* action — when asked to supply/borrow/repay/withdraw, close or adjust a position, or build an Aave transaction.
---

# Aave transaction preparation

Non-custodial: every tool here returns an **unsigned** transaction for the user's own wallet to sign. Say what a prepared transaction will do once signed, and that nothing has been sent.

The chain is **discover → inspect → simulate → build**, then hand over unsigned.

## Steps

1. **Discover** — `get_markets` with `symbols`, and `user` set to the sender, in this session even when a market looks familiar: selectors (v4 `reserveId`; v3 `market` + `token` + `chainId`) are deployment-specific and cannot be recalled. The `user` rows say what this wallet can actually supply or borrow before anything is built.
2. **Inspect** — `get_user_summary` for what the wallet already owes and how much room it has, and `get_reserve_details` where the reserve's own parameters bear on the action. A borrow or a withdraw sized without this is a guess.
3. **Simulate** — `preview_action` with the exact parameters you intend to build. Mandatory before every borrow and withdraw; run it for supply and repay too. An error-level warning means the action cannot succeed as specified: fix the inputs or tell the user, rather than building it.
4. **Build** — `prepare_action` with the same selectors and amount. Follow the returned plan in order: an approval step comes before the action, and a sent transaction is confirmed with `get_transaction_processed` before building one that depends on it.
5. **Hand over** — show the unsigned transaction, the simulated outcome (the health factor after, for anything touching debt or collateral), and every warning (warning level succeeds but must reach the user). Then stop: signing is the user's move.

## Rules

- Amounts are in main units (`"10.5"` = 10.5 USDC), never base units or wei.
- Borrowing needs collateral enabled: a plain supply backs nothing. Pass `enableCollateral: true` when the plan includes borrowing against it.
- The same chain — discover, inspect, simulate, build, hand over unsigned — applies to every other `prepare_*` tool (swaps, collateral toggles, e-mode, rewards, sGHO).

## Done when

- The simulation ran on the exact parameters that were built, and its outcome is in the answer.
- Every warning the server returned reached the user, by level.
- The transaction is presented unsigned, with the post-action health factor wherever debt or collateral moved.

## Why simulate first

`preview_action` is the cheapest place for an action to fail, and the only place that reports the position's shape: it returns the resulting health factor, which the build step does not. Skipping it costs a round trip on a refusal and, worse, hands the user a transaction whose effect on their health factor nobody has read. A clean simulation reports the position's own limits, not token allowances — an approval step can still be waiting in the plan.

View saved version →

---
name: tx-confirmation
description: Confirm what an Aave transaction did after the user signed it — "did it go through", "was my supply processed", "check my transaction" — by reading the position it left behind and comparing with what was simulated.
---

# Aave transaction confirmation

A transaction hash is not a result. The result is the position after, compared with the position that was simulated before.

## Steps

1. **Find it in the feed** — `get_user_activity` for the wallet, on the chain the transaction was sent to (v3 reads one market per call, so pass `chainId`). The matching `txHash` row gives the action, the asset and the amount as Aave indexed them. A hash that is not in the feed has not been processed by the protocol yet — or reverted, or was never mined.
2. **Read the position** — `get_user_summary` and `get_user_positions` for the wallet. The health factor and the balances the action should have changed are the confirmation.
3. **Compare** with the simulation from earlier in the conversation, if there was one: the `healthFactorAfter` it reported against the health factor now, the amount built against the balance change. A gap larger than accrued interest and price movement is worth naming.
4. **Clear the next step** — if a later step in the plan depended on this one (an approval before an action, a repay before a withdraw), the confirmation is what clears it. On v4, `get_transaction_processed` exists for exactly this: pass the hash and the `operations` array the build returned, and poll until `processed` is true before building the dependent step. It is v4-only and needs those operations; it does not look up an arbitrary hash.

## Rules

- Do not report success from the hash alone; the position read is the confirmation.
- A transaction that reverted or was never mined leaves the position unchanged: say that plainly, and that nothing was spent beyond gas.
- Aave's feed reads current state and history; it does not carry a receipt, block or gas figure. Where the user wants those, say they come from a block explorer, not from here.
- No signing here: this skill only reads.

## Done when

- The answer states whether the protocol has indexed the transaction, and the position's health factor and changed balances after it.
- Where a simulation preceded it, the answer compares simulated against actual.
- Where a dependent step was waiting, the answer says it can now be built.

View saved version →

---
name: yield-analysis
description: Compare Aave yields and rates — best APY for an asset, rates across chains or between V3 and V4, APY history and stability, GHO savings (sGHO) — before recommending where to supply or borrow.
---

# Aave yield and market analysis

## Steps

1. `get_markets` with `symbols` for the assets in question, no `chainId`, version `all`. The symbol filter is what makes v3 cross-chain — unfiltered v3 reads Ethereum alone.
2. Shortlist, then per candidate: `get_reserve_details` for risk parameters and the rate curve, `get_apy_history` for how the spot rate has moved.
3. GHO savings questions: `get_sgho_vault`. Its rate is governance-set, not utilisation-driven, and sGHO is not collateral — present it as savings, not as a lending position.

## Reporting rules

- State the coverage with the numbers: which chains were read (`chainsCovered`), which were not (`chainsNotCovered`), and that `chainsNotServed` chains hold no data here at all.
- Say whether the answer is a sample or the population. "Top 5 by APY" filtered from one call is a sample; only an unfiltered read of every covered chain supports "the best rate on Aave is…".
- Rank only **enterable** rates: skip rows flagged `isFrozen` / `isPaused` / cap-reached, and check `suppliable` / `borrowable` (v4) or `availableLiquidity` (v3) against the size in question. A great APY with no capacity is not an option.
- Spot APY is variable: for any recommendation, quote the recent range from `get_apy_history` next to the spot figure.
- v4 spokes sharing a hub share its rate — identical APYs across spoke rows are one underlying rate, not independent options.

## Done when

- Every chain read is named, and every chain not read is named as not-read.
- The answer says whether it is a sample or the population; "the best rate on Aave" appears only behind an unfiltered read of every covered chain.
- Every ranked row is enterable, with its capacity checked against the size asked for.
- Every spot APY quoted for a recommendation carries its recent range beside it.