What settled, against what was authorised.
Did anything happen on a chain at all?
chain-confirmed
The declared chain returned this transaction and it matches the receipt.
Confirmed on monad at 2026-08-05T07:49:28.228Z; the transaction's status, token, amountBaseUnits, transferTo match this receipt.
Is what settled what was authorised?
matched
Every field that could be compared agrees, and at least one field was compared.
What settled on chain matches what was authorised, on amount.
Two standings, never merged. A receipt can be confirmed on chain and still describe a settlement nobody authorised, so collapsing these into one badge is the misreading this whole layer exists to prevent. Ava reports this receipt as a fill only when the second says matched; this one reports isFill: true.
Authorised against settled
| field | authorised (receipt) | settled (chain) | verdict |
|---|---|---|---|
| amount | 1000000 | 1000000 | match |
| asset | 0x754704bc059f8c67012fed69bc8a327a5aafb603 | not recorded | unconfirmed |
| recipient | not recorded | not recorded | unconfirmed |
Of the 3 fields this receipt records, 1 agrees, 2 could not be compared at all. A row reading unconfirmed did not pass: it is one of the two sides having nothing to put beside the other.
chainClaim carries the authorised amount (amountBaseUnits), asset (token) and, when claimed, recipient (transferTo). Independently re-derive the same fields from txHash's own logs on a public node and compare them to settlement.compared[].settled yourself; settlement.compared[].status is Ava's own comparison, not a substitute for checking it.
Every field the two sides carry
| field | what the receipt claims | what the chain read recorded |
|---|---|---|
| chain | monad | monad |
| chain id | 143 | n/a |
| transaction succeeded | n/a | true |
| sender | 0x648530a71280b27558b4f2cac31dccedcbace77c | not recorded |
| contract called | 0x69a5f9ad4f96ebf0a0c792dd42a01cc5c0102fef | not recorded |
| token | 0x754704bc059f8c67012fed69bc8a327a5aafb603 | not recorded |
| amount (base units) | 1000000 | 1000000 |
| transfer from | not recorded | not recorded |
| transfer to | not recorded | not recorded |
| market | aave_v3:143:0x69a5f9ad4f96ebf0a0c792dd42a01cc5c0102fef | n/a |
Left is the receipt's own chainClaim. Right is attestation.observed, an independent read of the transaction stored at the time it was checked. No verdict column here on purpose: only the API states which pairs it compared, and that statement is the table above. “not recorded” on the right means the stored read carried no such value, which is precisely why the command below matters more than either column.
Check it without us
Ava published the comparison above. That is worth exactly as much as your ability to redo it, so here is the transaction on a block explorer and the command that reads it from a public node with no Ava software anywhere in the path.
curl -s -X POST https://rpc.monad.xyz \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0x1b23c35d5c7c58746961777fdc9eb468823be549a3784869ff0d71b326628af7"]}'- "status""0x1" (the transaction succeeded)
- "to"0x69a5f9ad4f96ebf0a0c792dd42a01cc5c0102fef
- "from"0x648530a71280b27558b4f2cac31dccedcbace77c
curl -s https://www.getava.xyz/v1/receipts/exec_lend_aave_62d2a6763c984af8be707a58/verifyFetch txHash from chain on any public node or explorer and check it succeeded.
addressed by executionId · requestId c885517a-55b6-412a-a3cb-979530452039