← AaveCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Aave
Snapshot Sep 30, 2026 · 23:00 UTC · version 1.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"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.",
"included_files": [],
"skill_md_contents": "---\nname: tx-confirmation\ndescription: 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.\n---\n\n# Aave transaction confirmation\n\nA transaction hash is not a result. The result is the position after, compared with the position that was simulated before.\n\n## Steps\n\n1. **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.\n2. **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.\n3. **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.\n4. **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.\n\n## Rules\n\n- Do not report success from the hash alone; the position read is the confirmation.\n- A transaction that reverted or was never mined leaves the position unchanged: say that plainly, and that nothing was spent beyond gas.\n- 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.\n- No signing here: this skill only reads.\n\n## Done when\n\n- The answer states whether the protocol has indexed the transaction, and the position's health factor and changed balances after it.\n- Where a simulation preceded it, the answer compares simulated against actual.\n- Where a dependent step was waiting, the answer says it can now be built.\n"
}SHA-256: ab30132ce70f1eb590594679f6283e34f19c2731b86704d7991f1a19d40279f2