AvalancheGo 1.15.2, released on October 22, 2026, moves the plugin interface to version 47 and requires plugins to update for compatibility. The release also states backward compatibility with 1.15.0. Read both statements: compatibility of the release does not mean every previously installed VM plugin can be left unchanged.
Start with the component that actually changed
The release notes are the starting point for an operator’s upgrade review. They also provide a separate path for nodes that last ran before Helicon. Read the instructions for that history before choosing a recovery or update procedure. A general recommendation to update is not enough to establish the right path for every existing database.
For a hosted-wallet user, this is infrastructure news rather than a personal token-migration request. For a node operator, make an inventory of the running process and the VM components it actually loads. A package downloaded onto the server is not evidence that the service behind a wallet’s endpoint has restarted with the intended combination.
Read the node version and VM interface separately
The official Info RPC documentation describes info.getNodeVersion, including node and VM versions and a rpcProtocolVersion field for the RPCChainVM protocol. That field should not be confused with the public API’s JSON-RPC message format. Record the values from the actual node under review; the documentation’s example is not a live network reading.
| Question for the operator | Relevant evidence | Separate question still open |
|---|---|---|
| Which process is serving the application? | The running node version and build identity | Are its VM components compatible? |
| Which VM interface is in use? | The plugin requirement and actual VM inventory | Has the intended chain completed its startup work? |
| Is that chain bootstrapped? | A chain-specific readiness result | Does the application call a supported method? |
| What happened to the user’s transfer? | The identified transaction on the intended chain | Has the receiving service credited it? |
The same Info API documents info.isBootstrapped for a specified chain. Use the relevant chain rather than treating one node-wide version string as proof that every service is ready. A readiness check and a transaction lookup serve different purposes; neither should be replaced with a screenshot of an installer reporting success.
An application can also be asking a retired question
Version 1.15.2 removes the previously deprecated C-Chain avax.getAtomicTxStatus method; the release directs integrations to avax.getAtomicTx. Review the documented behavior before adapting an application. An unsupported method response is not, by itself, a verdict that the transaction was rejected or that funds vanished.
In an illustrative support case, a balance screen stops updating after an infrastructure change. Keep the screen error, endpoint identity and exact requested method. The operator checks the component inventory and the application call, then investigates the particular transfer separately. This preserves the question that failed instead of turning every technical error into the same payment diagnosis.
- Identify the actual network, chain and endpoint used by the application.
- Record the serving node’s version and the loaded VM components, using authorized operational access.
- Compare that inventory with the release’s plugin compatibility requirement and upgrade notes.
- Check the relevant chain’s readiness and the application’s supported API methods.
- Resolve the original transaction outcome before considering any replacement transfer.
What to ask support when you do not operate the node
Provide the transaction reference, intended chain, observation time and exact error if available. Ask whether the problem concerns the endpoint, an unsupported query or the transfer’s actual result. Keep private keys and authentication secrets out of the message. This article did not install AvalancheGo, run a VM, query a live node or reproduce a customer incident.
Before a separate exchange, check supported coins and networks, the order workflow, and the instructions in the simple-swap form. A node release does not establish deposit support for every Avalanche chain at KOT.CASH. The receiving asset and network must match the actual order, regardless of which software version an operator runs.
FAQ
What should I check in the AvalancheGo 1.15.2 release notes?
Compare the release’s compatibility statement with its plugin requirement and upgrade path. Do not treat an updated node package as proof that every loaded component matches.
Where should I read the AvalancheGo source and release information?
Use the linked official ava-labs repository and Builder Hub documentation. Distinguish a documentation example from a response obtained from the node you operate.
What does an Avalanche node setup check prove about a transfer?
A component or readiness check answers its own infrastructure question. Investigate the identified transaction and receiving-service result separately.