# Meteora DLMM event coverage report — 0.7.57 final

## Scope

Version `0.7.57` closes `meteora_dlmm` from the local IDL and the dedicated local corpus.

Target program:

```text
LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo
```

Local IDL:

```text
idls/meteora_dlmm.LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.json
```

Final inventoried surface:

```text
76 IDL instructions
30 Anchor events
12 accounts
```

The local corpus additionally identified discriminator `75c73e67068e1fcb` as `initialize_preset_parameter_v2`. This discriminator was not present in the local IDL under that spelling, but the transaction logs contain `Instruction: InitializePresetParameterV2`, the account layout is stable, and the instruction creates a 36-byte DLMM-owned preset parameter account through the system program.

## Final validation summary

```text
cargo test -p kb_lib -> 460 passed / 0 failed
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
769 replayed
0 decode skipped
769 ledger upserts
646 unsafe ledger rows
106 trades
664 liquidity
1107 lifecycle
0 tokenAccount
424 candle upserts
instructionObservations = 8062
resetDeleted = 9898
catalog = 169 tokens / 218 pools / 218 pairs
```

## Closure checks

All blocking checks are clean:

```text
upstream_git fallback for locally covered meteora_dlmm entries -> empty
local instruction_audit observed -> 0
DLMM decoded events without coverage -> empty
successful non-materialized DLMM without explicit skip/policy -> empty
failed transaction business materialization -> empty
multi-target materialization -> empty
non-swap trade/candle safety -> empty
fee parent scalar without fee amount leg -> empty
orphan fee amount legs -> empty
limit/orderbook trade/candle double-count -> empty
logical duplicate coverage rows -> empty
```

The only coverage difference left is explained and non-blocking:

```text
close_bin_array observed 16 / materialized 14
14 successful transactions -> lifecycle materialized
2 failed transactions Custom 6015 -> decoded/audit only, no business materialization
```

## Materialization policy

### Trades and candles

Only instruction-level DLMM swaps can produce trades/candles:

```text
meteora_dlmm.swap
meteora_dlmm.swap2
meteora_dlmm.swap_exact_out
meteora_dlmm.swap_exact_out2
meteora_dlmm.swap_with_price_impact
meteora_dlmm.swap_with_price_impact2
```

Anchor `swap_event` and `swap2_evt` are materialized as lifecycle `swap_log` rows and never as trades/candles. This prevents double-counting when an instruction swap and an Anchor log describe the same user-visible swap.

### Liquidity and lifecycle

The following families are materialized when transactions are successful and context is reliable:

```text
add_liquidity*
remove_liquidity*
remove_all_liquidity
rebalance_liquidity
initialize_bin_array*
close_bin_array
go_to_a_bin*
initialize_position*
close_position*
increase_position_length*
decrease_position_length*
update_position_operator*
lb_pair_create_event
position_create_event
position_close_event
```

Position and bin lifecycle events are routed to `k_sol_pool_lifecycle_events` when the operation is structural rather than a direct liquidity amount delta.

### Fees

Fee parents are written to `k_sol_fee_events`. Amount legs are written to `k_sol_fee_event_amounts`.

Final observed amount-leg summary:

```text
claim_fee                  64 parents /  64 legs
claim_fee2                 63 parents /  88 legs
claim_fee_event           127 parents / 187 legs
claim_fee2_event           78 parents / 118 legs
composition_fee_event      51 parents /  63 legs
withdraw_protocol_fee      14 parents /  20 legs
zap_protocol_fee           13 parents /  13 legs
```

The inner SPL transfer recovery is explicitly allowlisted for DLMM fee event kinds. It is not inherited globally by future decoders.

### Rewards

Reward parents are written to `k_sol_reward_events`. Amounts are recovered only when a reliable inner SPL transfer or decoded amount is present.

Final observed scalar amount summary:

```text
claim_reward               15 parents /  1 scalar amount
claim_reward2              19 parents / 10 scalar amounts
claim_reward_event         34 parents / 25 scalar amounts
claim_reward2_event        19 parents / 10 scalar amounts
fund_reward                10 parents / 10 scalar amounts
fund_reward_event          10 parents / 10 scalar amounts
initialize_reward           9 parents /  0 amount
initialize_reward_event     9 parents /  0 amount
```

`initialize_reward` and `initialize_reward_event` remain without amount because they are configuration/initialization events, not executed reward transfers. No amount is fabricated from limits, bounds or configuration fields.

### Admin/config and orderbook

Admin/config events materialize to `k_sol_pool_admin_events`. Limit-order operations materialize to `k_sol_orderbook_events` and never to trade/candle tables.

Important promoted local corpus entry:

```text
75c73e67068e1fcb -> meteora_dlmm.initialize_preset_parameter_v2 -> k_sol_pool_admin_events
```

## Remaining non-observed surfaces

Non-observed IDL/account rows remain in coverage with `observed_count = 0` and `materialized_count = 0`. They are not blockers.

Examples:

```text
update_reward_duration
update_reward_funder
withdraw_ineligible_reward
migrate_position
account metadata rows
for_idl_type_generation_do_not_call
anchor_self_cpi_log registry row
```

## Decision

`0.7.57 meteora_dlmm` is closed. Do not add further DLMM Rust patches unless a new corpus proves a successful transaction that is decoded but not materialized and lacks an explicit skip/policy reason.

Next recommended work is not another DLMM patch: implement `0.7.58 demo4_program_surface_discovery` to display unknown or unsupported program surfaces without automatic materialization or automatic decoder promotion.
