This is a paragraph! Here's how you make a link: Neocities.
Here's how you can make bold and italic text.
Here's how you can add an image:
Understanding the Issue
Anchor IDL Generation Changes: Starting with Anchor v0.30.0, the IDL (Interface Definition Language) format and generation logic were significantly rewritten
solana.stackexchange.com
. This introduced breaking changes compared to the older IDL format (for example, fields like isMut/isSigner were renamed to writable/signer, and program account entries like system_program are represented with an address instead of a type). If your Anchor CLI or client is using the new IDL spec but your program’s IDL is generated in the old style (or vice versa), certain fields can appear missing or incompatible. In particular, missing "type" fields (e.g. "type": "publicKey") often indicate a mismatch or incomplete IDL generation.
Anchor CLI vs. Crate Version Mismatch: If your Anchor CLI version and Rust crate version don’t match, IDL generation can be incomplete. For example, using the Anchor 0.30+ CLI on a program that hasn’t enabled the new IDL features can lead to an IDL that lacks required fields. This is why it’s important to upgrade both the Anchor crates and the client/CLI in tandem
solana.stackexchange.com
. After the v0.30 rewrite, Solana Playground (and other tools) still produced the old-format IDL for a while; Anchor’s maintainers advised either sticking to anchor-lang 0.29.x or upgrading everything to 0.30+ together to avoid incompatibilities
solana.stackexchange.com
. In short, ensure your Anchor.toml, Cargo.toml, and frontend Anchor libraries are all on the same version (e.g. 0.30.1 or later) so that the IDL schema is consistent across build and usage.
Ensuring Full IDL Output
To get a fully populated IDL (with all expected "type" fields for accounts, including "publicKey" on Pubkey fields), take the following into account:
Enable the idl-build Feature: Starting in v0.30.0, Anchor requires using the idl-build feature to generate the new IDL format directly from your program’s code. If this feature is missing, Anchor will warn or produce an incomplete IDL. Make sure your program’s Cargo.toml has:
[features]
idl-build = ["anchor-lang/idl-build"]
(and similarly for anchor-spl if used). Not having this feature can result in an IDL missing top-level metadata or account type info. In fact, “IDL-build feature is missing” is a common error if this isn’t set, and the fix is to add that feature and rebuild
solana.stackexchange.com
. After enabling it, run anchor build again – it should regenerate the IDL with all fields properly included.
Verify the Raw IDL: Check the JSON in target/idl/soltix.json (or your program name). It should include a top-level "accounts" array with your account structs and their fields. For each field (e.g. a Pubkey), there should be a corresponding "type" entry. For example:
"accounts": [
{ "name": "MyAccount",
"type": { "kind": "struct", "fields": [
{ "name": "authority", "type": "publicKey" },
{ "name": "count", "type": "u64" }
] }
}
]
If you open this file and see a field with a name but no "type", that means the IDL generation failed to recognize the type. In a correct IDL, a Pubkey field must appear as "type": "publicKey"
forum.solana.com
. Should you find it missing, consider the causes below.
Account Struct Annotations: Ensure that every custom account struct in your program is properly annotated and implements the necessary traits. In Anchor, you should mark account structs with #[account] (to indicate it’s an account data structure). Also, the struct needs to derive serialization/deserialization traits so Anchor can embed it in the IDL. If you didn’t manually derive AnchorSerialize and AnchorDeserialize, add those (along with Debug, Default, etc. as needed). The Anchor macros usually enforce this, but it’s worth double-checking. A common cause of “type missing” in the IDL is a struct that Anchor couldn’t fully process. For example, one user had a custom struct not properly derived, and the fix was:
“When defining the struct, you need to use #[derive(Debug, Clone, AnchorSerialize, AnchorDeserialize)] so the struct can be properly deserialized and serialized….”
solana.stackexchange.com
If these traits are missing, Anchor might omit the struct’s fields in the IDL or not list the struct under the "accounts" section at all.
Avoid Unsupported Field Types: Anchor IDL knows how to handle Solana primitives (Pubkey -> "publicKey", u8/u64 -> "u8"/"u64", etc.) and other Anchor-defined types. However, if you use external types or complex types in your account, the IDL may drop the ball. For instance, if your account struct has a field of a type from another library or program, Anchor’s IDL generator will not automatically include the definition of that type. In the IDL JSON it might show up as { "name": "foo", "type": { "defined": "ExternalType" } } without actually defining what ExternalType is, effectively leaving the field type “blank.” This is exactly what happened when using a Metaplex MetadataArgs type in an Anchor instruction – the IDL referenced it but did not include its definition, causing an error
solana.stackexchange.com
. In your case, a missing "type": "publicKey" suggests the generator didn’t recognize the field as a Pubkey. This could happen if, say, you used an alias or a different module’s Pubkey type. Solution: Stick to types Anchor can parse, or if you need to use an external type, consider replicating the necessary parts in your program. The community recommendation for external types is to copy the definition into your program so that Anchor treats it as a local type and includes it in the IDL
solana.stackexchange.com
. In short, for each account field, ensure it’s either a primitive or a struct defined in your program (and included in the IDL). If you see "defined": "SomeType" in the IDL, make sure SomeType is actually present in the "accounts" or "types" sections of the IDL – otherwise the IDL is incomplete.
Check PDA Seeds in IDL: (Related to account entries) If your accounts use PDA derivation (#[account(seeds = [...], bump)]), Anchor’s IDL will include a "pda" object with seed information for that account. Each seed has a type, which could be a byte array, a string, a Pubkey, etc. Anchor v0.30 added explicit seed types in the IDL. If you notice seed types missing in the IDL, that was a known bug fixed in Anchor’s v0.30.0 release ("ts: Add missing IDL PDA seed types" is noted in the changelog)
anchor-lang.com
. Upgrading to the latest version should resolve that. For completeness, you might want to ensure you’re on Anchor 0.30.1+ which includes many IDL fixes.
Ensure Scripts Don’t Strip Data: It’s unlikely that your init_soltix.sh script intentionally removes the "type" fields, but it’s worth confirming. These scripts typically just copy the IDL or rename fields for your frontend. If the raw IDL (in /target/idl) looks correct, but the one in your front-end is missing the types, inspect the script. It might be doing a transformation (for example, converting all keys to camelCase or filtering certain fields). Given that Anchor’s IDL changed (e.g., isMut -> writable), a custom script could be out-of-date and mismatching fields. Ideally, you shouldn’t need a complex init script – you can directly use the JSON or the TypeScript types Anchor generates. In any case, verify that the IDL JSON is identical pre- and post-script.
Known Caveats & Workarounds
Anchor Version Bugs: If after all the above you still see the IDL missing pieces, you might be hitting an Anchor bug. Check the Anchor repository issues/changelog for your version. There were numerous patches post-0.30.0 addressing IDL generation problems (e.g., seed types, handling of certain generics, etc. in the IDL). Upgrading to the latest Anchor (or even the nightly, if you’re comfortable) might magically fix the IDL output. For example, Anchor 0.30.1 release notes mention fixes for recursive types and other IDL improvements (and 0.31.0+ continues to polish IDL generation). The safest path is to use the latest stable Anchor and matching client to get the benefit of these fixes.
Downgrade as a Last Resort: As a temporary workaround, some developers chose to stick with Anchor 0.29 if they needed the older IDL format (since it was stable for them) and hold off on 0.30 until their tooling caught up
solana.stackexchange.com
. If your project doesn’t strictly need 0.30+ features, and you suspect a bug in the new IDL system, using Anchor 0.29 (both program and client) could avoid the issue. This would make the IDL generate in the old format (which always included "type": "publicKey" for Pubkey fields in account structs). Only consider this if updating/patching isn’t feasible, because 0.29 is legacy now.
Manual IDL Patching: In a pinch, you can manually add the missing "type" in the JSON and use that IDL on the client side. This is not ideal long-term (since you’d have to remember to patch after each build), but it can unblock you during development/testing. For instance, if you see: { "name": "authority" } with no type, you can edit it to { "name": "authority", "type": "publicKey" } in the IDL file. The Anchor client will then recognize it. Again, treat this as a temporary hack – the goal is to get Anchor to output it correctly on its own.
Conclusion
In summary, Anchor should normally output all account fields with their types. Omitted "type" fields usually indicate something is out of sync or unsupported:
First, make sure you’re using a recent Anchor version and that your build is configured with the idl-build feature so the IDL is fully generated
solana.stackexchange.com
.
Second, ensure your account structs and fields are defined in a way Anchor understands (using the proper macros, traits, and no undefined external types)
solana.stackexchange.com
solana.stackexchange.com
.
Third, double-check that no post-processing is stripping those fields.
By addressing these, you should get a complete IDL where every account entry includes its type (e.g. public keys have "type": "publicKey", and so on), matching the expectations of your frontend. If problems persist, consider upgrading Anchor or looking for any open issues specific to your Anchor version – it might be a known bug that’s already patched in a newer release
anchor-lang.com
.
References
Anchor 0.30.0 release notes – IDL format overhaul (incompatible with old IDL)
solana.stackexchange.com
StackExchange – solution requiring Anchor CLI/TS version match and idl-build feature for proper IDL generation
solana.stackexchange.com
StackExchange – using external types (Bubblegum’s MetadataArgs) caused “IDL type not defined” until the type was included in the program’s IDL
solana.stackexchange.com
solana.stackexchange.com
StackExchange – reminder to derive serialization for custom structs so Anchor includes them in the IDL
solana.stackexchange.com
Solana IDL standard example – shows a Pubkey field correctly typed as "publicKey" in the IDL
forum.solana.com
(for comparison with your output).
To learn more HTML/CSS, check out these tutorials!