ChainLink not compatible with the latest Anchor versions

[IaroslavMazur]

The last Anchor version that seems to be supported is 0.30.1.

After having encountered the issue in a personal project, I've validated it against the Solana Starter Kit repo - and was able to consistently reproduce it.

Reproduction steps:

1. Clone solana starter kit
2. Run anchor build — observe that it succeeds
3. In Cargo.toml, update the anchor-lang dependency to 0.31.1
4. Update the corresponding NPM package with yarn upgrade @coral-xyz/anchor@0.31.1
5. Run anchor build again - and not that it fails.

Expected behavior:

The project should build successfully with newer Anchor versions (>= 0.31.1).

Actual behavior:

Build fails after upgrading to Anchor 0.31.1.

---

The output of the failed `anchor build` run that I'm getting

Compiling proc-macro2 v1.0.86
   Compiling unicode-ident v1.0.12
   Compiling version_check v0.9.4
   Compiling typenum v1.15.0
   Compiling libc v0.2.155
   Compiling syn v1.0.85
   Compiling serde v1.0.204
   Compiling unicode-xid v0.2.2
   Compiling thiserror v1.0.63
   Compiling serde_json v1.0.122
   Compiling semver v1.0.4
   Compiling anyhow v1.0.52
   Compiling itoa v1.0.1
   Compiling ryu v1.0.9
   Compiling cfg-if v1.0.0
   Compiling unicode-segmentation v1.8.0
   Compiling bs58 v0.5.1
   Compiling memchr v2.7.4
   Compiling autocfg v1.0.1
   Compiling heck v0.3.3
   Compiling generic-array v0.14.7
   Compiling proc-macro-error-attr v1.0.4
   Compiling once_cell v1.19.0
   Compiling proc-macro-error v1.0.4
   Compiling equivalent v1.0.1
   Compiling subtle v2.4.1
   Compiling hashbrown v0.14.5
   Compiling rustc_version v0.4.0
   Compiling indexmap v2.3.0
   Compiling ahash v0.8.11
   Compiling toml_datetime v0.6.8
   Compiling feature-probe v0.1.1
   Compiling winnow v0.5.40
   Compiling rustversion v1.0.17
   Compiling bv v0.11.1
   Compiling quote v1.0.36
   Compiling syn v2.0.72
   Compiling cpufeatures v0.2.1
   Compiling jobserver v0.1.32
   Compiling cfg_aliases v0.2.1
   Compiling zerocopy v0.7.35
   Compiling borsh v1.5.1
   Compiling cc v1.1.7
   Compiling memoffset v0.9.1
   Compiling toml_edit v0.21.1
   Compiling num-traits v0.2.19
   Compiling ahash v0.7.8
   Compiling block-buffer v0.10.4
   Compiling crypto-common v0.1.6
   Compiling digest v0.10.7
   Compiling sha2 v0.10.8
   Compiling hashbrown v0.13.2
   Compiling proc-macro-crate v3.1.0
   Compiling solana-frozen-abi-macro v1.18.20
   Compiling log v0.4.22
   Compiling constant_time_eq v0.3.0
   Compiling arrayvec v0.7.4
   Compiling arrayref v0.3.6
   Compiling lazy_static v1.4.0
   Compiling keccak v0.1.5
   Compiling solana-frozen-abi v1.18.20
   Compiling sha3 v0.10.8
   Compiling getrandom v0.2.15
   Compiling solana-program v2.0.25
   Compiling borsh-derive-internal v0.10.3
   Compiling borsh-schema-derive-internal v0.10.3
   Compiling borsh-schema-derive-internal v0.9.3
   Compiling borsh-derive-internal v0.9.3
   Compiling hashbrown v0.11.2
   Compiling bs58 v0.4.0
   Compiling either v1.13.0
   Compiling itertools v0.10.5
   Compiling base64 v0.21.7
   Compiling blake3 v1.5.1
   Compiling solana-program v1.18.20
   Compiling anchor-derive-space v0.31.1
   Compiling serde_derive v1.0.204
   Compiling thiserror-impl v1.0.63
   Compiling syn_derive v0.1.8
   Compiling bytemuck_derive v1.7.0
   Compiling num-derive v0.4.2
   Compiling solana-sdk-macro v2.0.25
   Compiling solana-sdk-macro v1.18.20
   Compiling borsh-derive v1.5.1
   Compiling bytemuck v1.16.3
   Compiling serde_bytes v0.11.15
   Compiling bincode v1.3.3
   Compiling toml v0.5.8
   Compiling anchor-lang-idl-spec v0.1.0
   Compiling anchor-syn v0.31.1
   Compiling anchor-lang-idl v0.1.2
   Compiling proc-macro-crate v0.1.5
   Compiling borsh-derive v0.10.3
   Compiling borsh-derive v0.9.3
   Compiling borsh v0.9.3
   Compiling borsh v0.10.3
   Compiling anchor-derive-serde v0.31.1
   Compiling anchor-attribute-access-control v0.31.1
   Compiling anchor-derive-accounts v0.31.1
   Compiling anchor-attribute-constant v0.31.1
   Compiling anchor-attribute-event v0.31.1
   Compiling anchor-attribute-error v0.31.1
   Compiling anchor-attribute-account v0.31.1
Error: Function _ZN4core5slice4sort6stable14driftsort_main17hdf5f1fdd79b92c70E Stack offset of 4104 exceeded max offset of 4096 by 8 bytes, please minimize large stack variables. Estimated function frame size: 4160 bytes. Exceeding the maximum stack offset may cause undefined behavior during execution.

Error: Function _ZN4core5slice4sort6stable14driftsort_main17h746ad55ff80ce04cE Stack offset of 4104 exceeded max offset of 4096 by 8 bytes, please minimize large stack variables. Estimated function frame size: 4160 bytes. Exceeding the maximum stack offset may cause undefined behavior during execution.

   Compiling chainlink_solana v1.0.0
   Compiling anchor-attribute-program v0.31.1
   Compiling anchor-lang v0.31.1
   Compiling chainlink-solana-demo v0.1.0 (/Users/iaros/Desktop/Projects/solana-starter-kit/programs/chainlink_solana_demo)
warning: unexpected `cfg` condition value: `custom-heap`
 --> programs/chainlink_solana_demo/src/lib.rs:7:1
  |
7 | #[program]
  | ^^^^^^^^^^
  |
  = note: expected values for `feature` are: `cpi`, `default`, `idl-build`, `no-entrypoint`, `no-idl`, and `no-log-ix-name`
  = help: consider adding `custom-heap` as a feature in `Cargo.toml`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default
  = note: this warning originates in the macro `$crate::custom_heap_default` which comes from the expansion of the attribute macro `program` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unexpected `cfg` condition value: `custom-panic`
 --> programs/chainlink_solana_demo/src/lib.rs:7:1
  |
7 | #[program]
  | ^^^^^^^^^^
  |
  = note: expected values for `feature` are: `cpi`, `default`, `idl-build`, `no-entrypoint`, `no-idl`, and `no-log-ix-name`
  = help: consider adding `custom-panic` as a feature in `Cargo.toml`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: this warning originates in the macro `$crate::custom_panic_default` which comes from the expansion of the attribute macro `program` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unexpected `cfg` condition value: `anchor-debug`
 --> programs/chainlink_solana_demo/src/lib.rs:7:1
  |
7 | #[program]
  | ^^^^^^^^^^
  |
  = note: expected values for `feature` are: `cpi`, `default`, `idl-build`, `no-entrypoint`, `no-idl`, and `no-log-ix-name`
  = help: consider adding `anchor-debug` as a feature in `Cargo.toml`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: this warning originates in the attribute macro `program` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unexpected `cfg` condition value: `anchor-debug`
 --> programs/chainlink_solana_demo/src/lib.rs:7:1
  |
7 | #[program]
  | ^^^^^^^^^^
  |
  = note: expected values for `feature` are: `cpi`, `default`, `idl-build`, `no-entrypoint`, `no-idl`, and `no-log-ix-name`
  = help: consider adding `anchor-debug` as a feature in `Cargo.toml`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: this warning originates in the derive macro `Accounts` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unexpected `cfg` condition value: `anchor-debug`
  --> programs/chainlink_solana_demo/src/lib.rs:40:10
   |
40 | #[derive(Accounts)]
   |          ^^^^^^^^
   |
   = note: expected values for `feature` are: `cpi`, `default`, `idl-build`, `no-entrypoint`, `no-idl`, and `no-log-ix-name`
   = help: consider adding `anchor-debug` as a feature in `Cargo.toml`
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
   = note: this warning originates in the derive macro `Accounts` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: arguments to this function are incorrect
  --> programs/chainlink_solana_demo/src/lib.rs:16:28
   |
16 |         let round: Round = chainlink::latest_round_data(
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
17 |             ctx.accounts.chainlink_program.to_account_info(),
   |             ------------------------------------------------ expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`
18 |             ctx.accounts.chainlink_feed.to_account_info(),
   |             --------------------------------------------- expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`
   |
   = note: `AccountInfo<'_>` and `AccountInfo<'_>` have similar names, but are actually distinct types
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
   = note: perhaps two different versions of crate `solana_program` are being used?
   = note: `AccountInfo<'_>` and `AccountInfo<'_>` have similar names, but are actually distinct types
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
   = note: perhaps two different versions of crate `solana_program` are being used?
note: function defined here
  --> src/lib.rs:98:8

error[E0277]: `?` couldn't convert the error to `anchor_lang::error::Error`
  --> programs/chainlink_solana_demo/src/lib.rs:19:10
   |
15 |       ) -> Result<()> {
   |            ---------- expected `anchor_lang::error::Error` because of this
16 |           let round: Round = chainlink::latest_round_data(
   |  ____________________________-
17 | |             ctx.accounts.chainlink_program.to_account_info(),
18 | |             ctx.accounts.chainlink_feed.to_account_info(),
19 | |         )?;
   | |         -^ the trait `From<solana_program::program_error::ProgramError>` is not implemented for `anchor_lang::error::Error`
   | |_________|
   |           this can't be annotated with `?` because it has type `Result<_, solana_program::program_error::ProgramError>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             `anchor_lang::error::Error` implements `From<ErrorCode>`
             `anchor_lang::error::Error` implements `From<ProgramErrorWithOrigin>`
             `anchor_lang::error::Error` implements `From<TryFromIntError>`
             `anchor_lang::error::Error` implements `From<anchor_lang::error::AnchorError>`
             `anchor_lang::error::Error` implements `From<anchor_lang::prelude::ProgramError>`
             `anchor_lang::error::Error` implements `From<std::io::Error>`
   = note: required for `std::result::Result<(), anchor_lang::error::Error>` to implement `FromResidual<std::result::Result<Infallible, solana_program::program_error::ProgramError>>`

error[E0308]: arguments to this function are incorrect
  --> programs/chainlink_solana_demo/src/lib.rs:21:35
   |
21 |         let description: String = chainlink::description(
   |                                   ^^^^^^^^^^^^^^^^^^^^^^
22 |             ctx.accounts.chainlink_program.to_account_info(),
   |             ------------------------------------------------ expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`
23 |             ctx.accounts.chainlink_feed.to_account_info(),
   |             --------------------------------------------- expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`
   |
   = note: `AccountInfo<'_>` and `AccountInfo<'_>` have similar names, but are actually distinct types
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
   = note: perhaps two different versions of crate `solana_program` are being used?
   = note: `AccountInfo<'_>` and `AccountInfo<'_>` have similar names, but are actually distinct types
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
   = note: perhaps two different versions of crate `solana_program` are being used?
note: function defined here
  --> src/lib.rs:90:8

error[E0277]: `?` couldn't convert the error to `anchor_lang::error::Error`
  --> programs/chainlink_solana_demo/src/lib.rs:24:10
   |
15 |       ) -> Result<()> {
   |            ---------- expected `anchor_lang::error::Error` because of this
...
21 |           let description: String = chainlink::description(
   |  ___________________________________-
22 | |             ctx.accounts.chainlink_program.to_account_info(),
23 | |             ctx.accounts.chainlink_feed.to_account_info(),
24 | |         )?;
   | |         -^ the trait `From<solana_program::program_error::ProgramError>` is not implemented for `anchor_lang::error::Error`
   | |_________|
   |           this can't be annotated with `?` because it has type `Result<_, solana_program::program_error::ProgramError>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             `anchor_lang::error::Error` implements `From<ErrorCode>`
             `anchor_lang::error::Error` implements `From<ProgramErrorWithOrigin>`
             `anchor_lang::error::Error` implements `From<TryFromIntError>`
             `anchor_lang::error::Error` implements `From<anchor_lang::error::AnchorError>`
             `anchor_lang::error::Error` implements `From<anchor_lang::prelude::ProgramError>`
             `anchor_lang::error::Error` implements `From<std::io::Error>`
   = note: required for `std::result::Result<(), anchor_lang::error::Error>` to implement `FromResidual<std::result::Result<Infallible, solana_program::program_error::ProgramError>>`

error[E0308]: arguments to this function are incorrect
  --> programs/chainlink_solana_demo/src/lib.rs:26:28
   |
26 |         let decimals: u8 = chainlink::decimals(
   |                            ^^^^^^^^^^^^^^^^^^^
27 |             ctx.accounts.chainlink_program.to_account_info(), 
   |             ------------------------------------------------ expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`
28 |             ctx.accounts.chainlink_feed.to_account_info())?;
   |             --------------------------------------------- expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`
   |
   = note: `AccountInfo<'_>` and `AccountInfo<'_>` have similar names, but are actually distinct types
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
   = note: perhaps two different versions of crate `solana_program` are being used?
   = note: `AccountInfo<'_>` and `AccountInfo<'_>` have similar names, but are actually distinct types
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
note: `AccountInfo<'_>` is defined in crate `solana_program`
  --> src/account_info.rs:19:1
   = note: perhaps two different versions of crate `solana_program` are being used?
note: function defined here
  --> src/lib.rs:82:8

error[E0277]: `?` couldn't convert the error to `anchor_lang::error::Error`
  --> programs/chainlink_solana_demo/src/lib.rs:28:59
   |
15 |       ) -> Result<()> {
   |            ---------- expected `anchor_lang::error::Error` because of this
...
26 |           let decimals: u8 = chainlink::decimals(
   |  ____________________________-
27 | |             ctx.accounts.chainlink_program.to_account_info(), 
28 | |             ctx.accounts.chainlink_feed.to_account_info())?;
   | |                                                          -^ the trait `From<solana_program::program_error::ProgramError>` is not implemented for `anchor_lang::error::Error`
   | |__________________________________________________________|
   |                                                            this can't be annotated with `?` because it has type `Result<_, solana_program::program_error::ProgramError>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             `anchor_lang::error::Error` implements `From<ErrorCode>`
             `anchor_lang::error::Error` implements `From<ProgramErrorWithOrigin>`
             `anchor_lang::error::Error` implements `From<TryFromIntError>`
             `anchor_lang::error::Error` implements `From<anchor_lang::error::AnchorError>`
             `anchor_lang::error::Error` implements `From<anchor_lang::prelude::ProgramError>`
             `anchor_lang::error::Error` implements `From<std::io::Error>`
   = note: required for `std::result::Result<(), anchor_lang::error::Error>` to implement `FromResidual<std::result::Result<Infallible, solana_program::program_error::ProgramError>>`

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
warning: `chainlink-solana-demo` (lib) generated 10 warnings (5 duplicates)
error: could not compile `chainlink-solana-demo` (lib) due to 6 previous errors; 10 warnings emitted

[BlockChomper]

Having the same issue, there appears to be a crate mismatch between what chainlink_solana crates and anchor is providing in the new version. Issue lies with the solana program it seems.

[BlockChomper]

Dropping my Cursor notes on the issue. From my end it's not building out of the box with Anchor 0.30.1 either fyi.

Understanding Chainlink Solana Integration: Type Mismatches and Crate Compatibility Issues

Key Facts and Root Causes

1. Multiple AccountInfo Types Conflict

The core issue stems from having two different AccountInfo types from different crates:

1. Anchor's AccountInfo: Imported via anchor_lang::prelude::*
2. Solana Program's AccountInfo: Used by the chainlink_solana crate

These types have identical names but are technically different Rust types, leading to compiler errors like:

error[E0308]: arguments to this function are incorrect
  --> programs/chainy/src/lib.rs:93:21
   |
93 |         let round = chainlink::latest_round_data(
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
94 |             chainlink_program_info.clone(),
   |             ------------------------------ expected `AccountInfo<'_>`, found a different `AccountInfo<'_>`

2. Re-exported vs. Direct Dependencies

Anchor re-exports solana_program crate, leading to two potential sources:

• Direct import: use solana_program::account_info::AccountInfo
• Anchor re-export: use anchor_lang::solana_program::account_info::AccountInfo

When you add solana-program as a direct dependency alongside Anchor, you can get version mismatches or multiple versions of the same types, resulting in warnings like:

WARNING: Adding `solana-program` as a separate dependency might cause conflicts.
To solve, remove the `solana-program` dependency and use the exported crate from `anchor-lang`.
`use solana_program` becomes `use anchor_lang::solana_program`.

3. Version Incompatibility

Even when using the same source for imports, version differences between Anchor's solana-program and chainlink_solana's expected solana-program can cause mismatches:

• Anchor might use version X of solana-program
• chainlink_solana might be built against version Y

This creates subtle incompatibilities because both crates may be importing nominally identical types that have different internal implementations or memory layouts.

4. Lack of Type Conversion Functions

There's no provided way to directly convert between the different AccountInfo types:

• Attempts to create converters (like account_info_to_solana_account_info) fail because the internal fields have different types or access patterns
• Fields like lamports and data in Anchor's AccountInfo are wrapped in RefCell<&mut T> while in solana_program they may have different wrappers

5. RefCell vs. Direct References

The implementation of AccountInfo in Anchor uses RefCell for interior mutability:

error[E0308]: arguments to this function are incorrect
  --> programs/chainy/src/lib.rs:51:5
   |
55 |         account.lamports.as_ref(),
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: expected mutable reference `&mut u64`
                      found reference `&RefCell<&mut u64>`

This fundamental difference in how data is accessed and modified makes direct conversion impossible.

6. Error Type Mismatches

Different error types between the crates cause incompatibilities when using the ? operator:

error[E0631]: type mismatch in function arguments
  --> programs/chainy/src/lib.rs:96:19
   |
   = note: expected function signature `fn(solana_program::program_error::ProgramError) -> _`
              found function signature `fn(anchor_lang::prelude::ProgramError) -> _`

Anchor uses its own error types, while chainlink_solana uses Solana's native error types.

7. Macro Dependencies and Conflicts

Both Anchor and Chainlink Solana use macros that may have hidden dependencies or assumptions about the environment:

error: proc-macro crate is missing its build data
  --> programs/chainy/src/lib.rs:13:1
   |
13 | declare_id!("6EgSg9qxKk7VzxBKep7U4MyvAM94J1P7EjJsHTS6Qqbh");

These macro issues can be challenging to debug because they happen during compile-time expansion.

8. Getrandom Crate Issues

The getrandom crate, used by dependencies, causes compilation problems on some targets:

error: target is not supported, for more information see: https://docs.rs/getrandom/#unsupported-targets
   --> src/lib.rs:267:9

This is particularly problematic when compiling for Solana's BPF (Berkeley Packet Filter) target.

Solutions Implemented

1. Direct CPI Approach

Instead of using the chainlink_solana crate, we implemented direct Cross-Program Invocation (CPI) to call the Chainlink program:

let instruction = Instruction {
    program_id: *ctx.accounts.chainlink_program.key,
    accounts: vec![
        AccountMeta::new_readonly(*ctx.accounts.chainlink_feed.key, false),
    ],
    data: vec![LATEST_ROUND_DATA],
};

invoke_signed(
    &instruction,
    &[
        ctx.accounts.chainlink_program.to_account_info(),
        ctx.accounts.chainlink_feed.to_account_info(),
    ],
    &[],
)

This bypasses type compatibility issues by using Solana's native instruction mechanism.

2. Manual Data Parsing

Instead of using chainlink_solana's convenience functions, we directly parse data from the accounts:

let price_offset = 8;
let feed_data = feed_account.try_borrow_data()?;
let price_bytes = &feed_data[price_offset..price_offset+16];
let price = i128::from_le_bytes([
    price_bytes[0], price_bytes[1], /* ... */,
]);

This approach avoids type conflicts entirely but requires understanding the exact data layout of Chainlink's feed accounts.

3. Simplified Architecture

We created a design that separates concerns:

• An on-chain program that handles direct CPI and data storage
• An understanding that more complex integration might be better handled at the client level

[IaroslavMazur]

@BlockChomper, thanks for your input! 🤝

Although this is a serious issue, it's been almost 10 days since I created it - and there has been no reaction from the ChainLink team, so far. Maybe, we should tag someone from the team explicitly for a quicker resolution... 🤔

[BlockChomper]

Hey @krebernisak please see above for a major conflict we are encountering with between the Chainlink crate / Anchor / Solana program please and give us your feedback when possible. @IaroslavMazur also pinged a Chainlink devrel externally so hopefully that will speed things along.

[IaroslavMazur]

Thank you for the pings, @BlockChomper!

Let's hope for a quick resolution of the issue now 🥺

[augustbleeds]

Hey there. Sorry for the delay, our team just learned of this want today through slack (we typically don't monitor the Github issues, but will going forward). We'll address this in an upcoming sprint. If I understand correctly, the crate just needs to be updated to use solana 2.x.

[BlockChomper]

Hey thanks for the response, I believe that's the core of the issue but not sure if anything else dependency wise needs to be updated.

[IaroslavMazur]

Thanks for your reply, @augustbleeds!

we typically don't monitor the Github issues

GitHub is the 1st place a dev would think about when reporting an issue wrt a public repository, so, you should, really, be monitoring the repo for new issues.

We'll address this in an upcoming sprint.

Could you give us an ETA for when the respective release of Chainlink should be published?

[BlockChomper]

@augustbleeds 2nd request for an ETA on fix pls, we are integrating with Chainlink and want to deploy asap so this is a hard blocker for us unless you have a viable workaround?

[pappas999]

Hi @BlockChomper , thanks for reaching out here and appreciate the urgency. We (DevRel) and internally pushing for a fix on this asap, let me try get back to you with an ETA in the next 24 hours.

[BlockChomper]

Much appreciated 🙏🏽

[BlockChomper]

@pappas999 Any movement on this?

[pappas999]

@pappas999 Any movement on this?

The team is picking it up in the next sprint @BlockChomper, apologies I don't have a more precise ETA, but I'll come back as soon as I do.

Just to clarify, you're saying that your specific issue is that it doesn't support 0.31 or higher, and only up to 0.30.1 in its current form?

[pappas999]

Hi @BlockChomper, FYI I published a branch of the Solana Starter Kit that I've successfully got working with Anchor 0.31.1. As a temporary workaround perhaps you could take a look at this and use it as a reference for your project until the official fix is in?

Take note I had to create a local version of chainlink_solana and reference that in the code, plus some other various change to get everything upgraded and working. LMK if you have any questions, you can reach out to me via TG as well, pappas99

[IaroslavMazur]

@pappas999, any update here?