Release Channels and Artifact Verification

For each axelard binary release, operators must verify the SHA256 checksum against the signed checksums.txt file published in the official GitHub release. This process confirms the binary has not been tampered with during download or mirroring. Use shasum -a 256 locally and compare the output. Chainscore can help infrastructure teams automate this step in their CI/CD pipeline to prevent deployment of corrupted or malicious binaries.

Official Axelar Docker images are signed using Cosign. Before pulling and running a container, operators should verify the image signature against the Axelar maintainers' public key. This mitigates the risk of running a compromised image from a registry. The verification command pins the expected image digest, ensuring immutability. Chainscore can review a team's container admission control policies to enforce signature verification before deployment.

For teams building from source, it is critical to verify that the Git tag for a release points to the expected commit hash and that the tag is signed by a recognized maintainer's GPG key. This prevents supply-chain attacks where a malicious tag is introduced. Use git verify-tag <version> to check the signature. Chainscore can assist in establishing a secure, reproducible build process that anchors on verified commits.

Start with the official Axelar documentation when validating operational assumptions around axelar-core releases, validator procedures, GMP infrastructure, and network-specific instructions. Treat docs as the baseline for supported workflows, but do not rely on a documentation page alone for binary provenance. Operators should cross-check any documented version or upgrade instruction against the corresponding GitHub release, tag, governance context, and their own staging-node test results before production rollout.

Use the axelar-core release page as the primary distribution checkpoint for release notes, tagged versions, and downloadable artifacts when they are published by the Axelar maintainers. Before installation, record the release tag, asset names, checksum files, signature files if present, and whether the release is marked as a prerelease. Validator and relayer teams should avoid pulling unpinned artifacts from automation scripts; deployment pipelines should require an explicit version, expected checksum, and human approval for mandatory upgrades.

For higher-assurance environments, verify that the release tag points to the expected commit and review the diff from the previously deployed axelar-core version. This is especially important when a release affects consensus behavior, message routing, gateway interaction, relayer assumptions, or API compatibility. Teams that build from source should use a clean, reproducible build environment, pin dependencies, archive build logs, and compare the resulting binary hash against the internally approved artifact before rollout.

Monitor the axelar-core security advisories page alongside release notes. A routine patch release, hotfix, or mandatory upgrade may be connected to a vulnerability, unsafe configuration, or dependency issue that is not obvious from version numbering alone. Security teams should subscribe to repository notifications, maintain an internal severity-mapping process, and define escalation paths for validator nodes, relayer services, API gateways, and downstream applications that depend on Axelar GMP or Interchain Token Service behavior.

If an Axelar release or container distribution channel publishes Sigstore-compatible signatures, use cosign to verify the image digest before deployment. Do not treat a container tag as an integrity guarantee: tags can move, registries can be mirrored, and CI systems can pull the wrong artifact if the digest is not pinned. If no signature is provided for a required artifact, record that exception in the release approval ticket and compensate with checksum verification, source review, and staged canary deployment.

When a release is tied to a coordinated network upgrade, confirm the governance and activation context before deploying. Operators should verify whether an upgrade proposal, activation height, minimum-version policy, or deadline applies to the release, then align Cosmovisor configuration, rollback procedures, and monitoring alerts accordingly. Block explorers such as Mintscan are useful for observing Axelar governance proposals and chain state, but teams should still verify final operational instructions against Axelar’s canonical release and documentation sources.