> For the complete documentation index, see [llms.txt](https://docs.townsq.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.townsq.xyz/institution-backed-yield-vault-features/yield-vault/operations/indexing.md).

# Indexing

## Running your own indexer

If you would rather index the vault contracts yourself, this section covers what to listen for and the traps worth knowing about before you start.

### What you need

Three things per vault:

1. The chain and the vault contract address.
2. The block the vault was deployed at. Get this from the block explorer rather than guessing. Starting a few million blocks early only costs you a longer backfill, but starting even one block late means you miss requests and can never settle them correctly.
3. The vault ABI. Ask us for it, or pull the verified ABI from the explorer.

### Events to index

| Event                                            | What it means                                                      |
| ------------------------------------------------ | ------------------------------------------------------------------ |
| `RedemptionRequested`                            | A user has queued a withdrawal. Create your row here.              |
| `Withdraw`                                       | The withdrawal settled. Close the row.                             |
| `WithdrawalExecuted`                             | The settlement was operator driven, not user driven.               |
| `CooldownPeriodUpdated`                          | The cooldown changed. Read the note below, this one is not simple. |
| `FeeSet`, `ManagerUpdated`, `Paused`, `Unpaused` | Vault configuration changed.                                       |

`RedemptionRequested` and `Withdraw` are the two you cannot skip. The rest are optional depending on what you are building.

### Cooldown changes are retroactive

When `CooldownPeriodUpdated` fires, the new period applies to requests that are already open, not just to new ones. A request created last week can become claimable earlier or later than the date you first calculated.

On that event, recompute `claimableAt` for every open request in that vault as `requestedAt + newPeriod`. If you store a claimable date and never revisit it, your queue will drift away from what the contract actually allows.

### Withdraw and WithdrawalExecuted land in the same transaction

When an operator settles on a user's behalf, the contract emits `Withdraw` first and `WithdrawalExecuted` second. By the time the second event arrives, the request is already closed.

So do not treat `WithdrawalExecuted` as the completion. Treat it as a flag on a row you have already closed, and match it using the transaction hash plus the user address. If you look for an open request, you will find nothing, because `Withdraw` closed it a moment earlier.

### Pause emits twice

`pause()` calls the internal `_pause()`, which emits `Paused`, and then the vault emits `Paused` again. You get two identical logs in one transaction.

Keep that handler idempotent. Setting a boolean is safe. Incrementing a counter is not.