Why Explorer Compatibility Matters
Explorer-side reflection uses the published ABI plus the configured root types to decide how to decode instruction, account, and event bytes. The reflector APIs used by explorer tooling expect:instruction-rootfor instruction payloadsaccount-rootfor account dataeventsfor emitted event payloads
Required Metadata
Setabi.options.program-metadata.root-types on the published ABI.
What Each Root Type Does
| Root type | What explorer uses it for | What happens if it is missing |
|---|---|---|
instruction-root | Decode transaction instruction bytes | Instruction reflection fails |
account-root | Decode account data views | Account reflection fails |
events | Decode emitted events | Event reflection fails |
Prefer A Single Discriminated Instruction Root
Explorer instruction reflection works best when the ABI exposes one discriminated instruction envelope such asCounterInstruction, instead of only a set of unrelated per-instruction structs.
That root type should:
- include a tag or discriminator field
- point the payload enum at the correct tag field
- contain every published instruction variant
Minimal Canonical Example
Publishing Checklist
- add
program-metadata.root-types - make the instruction root a single discriminated envelope
- validate locally with Validation and roundtrip testing
- publish the ABI with Publishing and Iteration
- inspect the published artifact with Explorer MCP if explorer reflection still looks wrong
Open Next
- Examples for the same pattern alongside other public ABI excerpts
- Publishing and Iteration for the publish flow
- ABI Account for the exact CLI syntax