The Core Loop
The highest-value local loop is:Recommended Workflow
Analyze the schema
Run ABI Analyze first to resolve imports, validate layout rules, and inspect IR if needed.
Generate TypeScript
Run ABI Codegen and use the generated TypeScript types/helpers to build real instruction data.
Reflect the bytes back
Use ABI Reflect on the resulting binary payload. If the reflected values do not match what you intended to send, the ABI is not ready yet.
Only then move to deployment
Once the payload roundtrip is correct, move to Publishing and Iteration.
Why This Matters
ABIs are handwritten, so “looks right” is not good enough. The roundtrip loop proves:- the schema resolves cleanly
- codegen can consume it
- the produced bytes match the schema when decoded back out
Useful Command Split
| Goal | Best tool |
|---|---|
| Resolve imports and type graph | ABI Analyze |
| Inspect layout IR or helper previews | ABI Analyze with --print-ir, --print-footprint, or --print-validate |
| Generate TS for payload building | ABI Codegen |
| Decode or validate a captured payload | ABI Reflect |
| Normalize imports before publish or browser use | ABI Flatten, ABI Prep for Publish, or ABI Bundle |
Tooling Reality Today
A practical testing stack today often looks like:- use ABI codegen to generate TypeScript
- use
thru-sdkto submit the transaction - use ABI reflection tooling or the explorer to decode instruction, account, or transaction data afterward
thru-sdk to send the transaction.
Common Gotchas
- A schema can pass
analyzeand still be wrong for the actual bytes you are building. - Generated code can expose awkward package or type structure that is hard to notice from YAML alone.
- Dynamic layouts need special attention; always prefer a real reflection roundtrip over eyeballing the schema.
- If context is tight,
analyzeplusreflect --validate-onlyis the fastest high-signal check.