BUILT A BOT THAT MIGRATES SOLANA SMART CONTRACT FILES AUTOMATICALLY
Varl9994 min read·Just now--
How I automated 90% of the Anchor IDL migration using AI-powered codemods, tested on real production repos
Anchor upgraded its IDL format from v0 to v1, and suddenly all your JSON files are outdated. The schema changed completely. Fields got renamed. Types got restructured. Events turned into type definitions. Discriminators went from simple numbers to 8-byte arrays.
For a single project it is hectic. For a team managing ten or twenty smart contracts, it becomes a real problem.
So I built a codemod to fix it automatically.
What is a codemod?
A codemod is a tool that reads your code or config files, understands their structure, and rewrites them according to a set of rules. Think of it like find-and-replace, but smart enough to understand context.
Instead of you manually going through every JSON file and updating field names, the codemod does it for you in seconds.
What exactly changed between Anchor IDL v0 and v1?
Here is the short version of what the migration has to handle:
The spec field has to be updated from a version number string to “0.1.0”. Every instruction and account field has to be converted to snake case. The accounts array inside instructions became a new structure. Types like u8, u64, publicKey got new formatting rules. Events, which used to be their own top-level array, now have to be converted into type definitions with a special attribute. Discriminators changed from single numbers to arrays of 8 bytes. PDAs and seeds got entirely new structures.
That is a lot of things to get right, especially when you have complex types with nested generics or unusual naming conventions.
How I built the migration tool
I used the Codemod platform, which gives you two building blocks: deterministic transforms and AI steps.
The deterministic step uses a library called JSSG (JavaScript AST Grep) to parse the JSON files and rewrite them precisely. This is the fast, reliable part. It handles straightforward patterns with zero guesswork.
The AI step uses GPT-4o to handle the edge cases that are too unpredictable for rigid rules. Things like unusual type combinations, deeply nested generic structures, or events with complex field types.
Together the two steps form a workflow:
Step 1 handles about 90 percent of every file automatically and correctly.
Step 2 catches the remaining tricky cases using AI reasoning.
The 12 rules I automated
Here are the specific things the codemod handles without any human involvement:
Adds the correct metadata header including the spec field set to “0.1.0”.
Converts all names to snake case across instructions, accounts, and types.
Rewrites the instruction accounts array into the new discriminator-based format.
Converts all primitive types to the new schema format.
Flattens complex account structures.
Converts events into type definitions with the correct event attribute.
Generates 8-byte discriminators from scratch.
Removes fields that no longer belong in v1.
Restructures PDAs and seeds.
Handles defined type references correctly.
Removes duplicate type entries.
Skips files that are already v1 so nothing gets broken twice.
Real world testing
I ran it against four real production IDL files from actual open source Solana projects.
The first was the Marinade Finance IDL. This is one of the largest liquid staking protocols on Solana. The IDL has 28 instructions, 25 events, and dozens of complex types. The codemod migrated all of it correctly.
The second was Marinade Referral, a companion program with 9 instructions.
The third was SPL Account Compression, a Solana Program Library project with 10 instructions and 10 type definitions.
The fourth was SPL Managed Token with 8 instructions.
Every single one passed validation. The output matched the expected v1 format exactly, with correct discriminators, correct type structures, and zero leaked v0 fields.
How the validation works
After migration, I ran a validation script that checks every output file for the following:
The spec field must be “0.1.0”. All required top-level keys must be present. Every instruction must have an 8-byte discriminator. There must be no duplicate type names. There must be no v0-only fields left behind.
All four real-world IDLs cleared every single check.
Why this matters
The Anchor team is moving fast. If you are building on Solana and want to use the latest tooling, you need your IDLs in the v1 format. Doing that by hand for a large program takes hours and is error-prone.
With this codemod you point it at your project folder and it finds every matching IDL file automatically, migrates it, and leaves it ready to use.
For a team migrating ten contracts, this saves an entire day of careful, boring, mistake-prone work.
Where to find it
The codemod is published on the Codemod registry here:
https://app.codemod.com/registry/anchor-idl-v0-to-v1
You can run it on your own project with:
npx codemod anchor-idl-v0-to-v1
The source code including all test fixtures and the real-world validation results is available on GitHub.
Final thoughts
The biggest surprise while building this was how much complexity hides inside what looks like a simple JSON migration. Anchor IDL v1 is not just a few renamed fields. It is a fundamentally different schema, and getting every edge case right required a lot of careful reading of the Anchor source code and testing against real programs.
The combination of deterministic transforms for the predictable parts and AI for the unpredictable parts turned out to be exactly the right approach. Neither alone would have been enough.
If you are working on Solana and still have v0 IDLs in your project, give it a try. It should just work.
