Avalanche ICM Relayer 1.8.3 was released on October 20, 2026 with a fix for a memory leak present in 1.8.2. For an operator, that calls for a component and resource review. For someone waiting on a cross-chain operation, the release alone does not establish what happened to their particular message or destination payment.
Keep the scope of the fix visible
The release note identifies the affected version and the memory fix. It does not publish a universal memory limit, a recovery deadline for every message or evidence that every relayer operator has deployed the update. Do not add those claims when explaining the news to a user.
The ICM Services repository describes the relayer as an offchain delivery service configured for particular source and destination chains. Identify whether that component is part of the route being investigated. A general Avalanche transaction and a message processed by a specific relayer require their own operational context.
Use two observation records after an update
One record concerns the process: which binary is running, when it started, what resource measurement was taken and what workload was present. The other concerns the message: the source evidence, relay submission and destination outcome. Keeping them separate helps avoid treating a successful restart as proof that a waiting user’s operation completed.
| Observation | What to retain | What it does not prove |
|---|---|---|
| Process memory changed | Measurement type, time, workload and process identity | That a particular message was delivered |
| The relayer restarted | Running version, restart time and relevant logs | That all earlier work has been reconciled |
| A source message is identified | Its source chain and matching reference | That the destination accepted the relay |
| A destination transaction is found | The matching execution result | That the receiving product credited the intended user |
For an illustrative review, memory might fall after a restart while a message still lacks a known destination outcome. Investigate both observations rather than calling the transfer fixed. A single memory reading also cannot establish that a leak is resolved under every workload. Compare like measurements over an appropriate observation period without inventing a published performance target.
Do not create a new load problem while clearing a backlog
The current relayer README notes that concurrent message processing can involve multiple RPC requests and that excessive concurrency can cause failures. Review the actual configuration and provider conditions before increasing work in parallel. A memory-fix announcement is not evidence that every dependency can absorb an unlimited catch-up burst.
If changing configuration as well as software, record both changes. Otherwise a before-and-after comparison may attribute an improvement or regression to the wrong cause. Preserve the relevant message records through the investigation; do not discard the evidence needed to establish an earlier outcome merely to make a dashboard look clear.
- Identify the relayer instance and whether its configured route includes the message in question.
- Record the running release, relevant configuration changes and resource observations.
- Compare source, relay and destination evidence for each unresolved operation.
- Review concurrency and dependency limits before increasing catch-up work.
- Confirm the original outcome before considering a replacement payment or declaring the case closed.
What a user should ask the operator
Provide the source transaction, intended networks and observation time. Ask which stage has been verified and which reference connects it to the destination result. The public relayer guide explains the delivery role, but its older installation examples should not replace current release instructions. This article did not run a relayer, profile its memory or test a live message.
Before a separate exchange, review supported coins and networks, the order workflow, and the instructions in the simple-swap form. This release does not establish an ICM integration at KOT.CASH. Use the actual order records to investigate that service’s transfer rather than assuming a shared infrastructure cause.
FAQ
Does the Avalanche ICM update prove that my message arrived?
Check the message’s source, relay and destination evidence separately. A software release or a successful restart is not a destination receipt.
What should an Avalanche Warp Messaging operator compare after the fix?
Keep process and workload observations alongside the unresolved message records. Do not infer a universal resource limit or delivery deadline from the brief release note.
Does an AvalancheGo release number identify the ICM Relayer version?
Identify the actual component and its running release. Review node and relayer compatibility instead of treating their version labels as interchangeable.