FORESHOCK

Protocols

Request coverage

Every protocol here carries a dated score and the share of it backed by independently verified evidence. Where that share is still thin the assessment says so, is marked Low-signal rather than given a risk band, and holds every unevidenced category at the neutral midpoint instead of assuming it safe. Every score and its reasoning are free to read; the underlying dependency, incident and audit records are part of a plan. Each reading here is fixed at the date beside it. Re-scoring never stops, but a changed reading reaches plan holders on the day it changes rather than this page, which is what a plan is for. How a score is built, how to read one, and how the rubric was tested against real exploits are all in the methodology.

Coverage grows three ways: protocols Foreshock selects at its own discretion, protocols requested through the Request coverage button, and sponsored assessments delivered on an agreed timeline. No path has a guaranteed date except sponsorship.

Scores run from 0, the safest reading, to 100, the riskiest, where 50 is the neutral midpoint every unverified category is held at. Red marks a protocol scoring 50 or above, the band called Elevated: worse than neutral on the evidence gathered. Amber marks one below it, called Moderate. The boundary is fixed. It does not move as coverage grows, and it is not fitted to any backtest result.

Axelar

Axelar official site N/A

Multi-Chain

:

  • Evidence: this reading is based on 100% of the scored weight, verified against named sources. Categories without verified data are excluded from the reading, never counted as safe.
  • Validation: the rubric is backtested against past exploits of protocols in the same TVL, age and category bucket. None has been evaluated for this one yet, so the reading rests on its evidence alone.
In short

Foreshock's independent reading of Axelar is Moderate risk, 35.0 out of 100, as of 7 September 2026. The largest single contributor to that reading is dependency risk: uses 1 oracle (Axelar IS the bridge, so the dependency question inverts: what it depends on is its own validator set and their independent chain nodes, and its own docs are unusually explicit about the trust model. The gateway on each chain 'is controlled by a key, which is held jointly by all Axelar validators', split into shares weighted by stake, and 'can only allow actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold'. Voting is quadratic for cross-chain validation: 'The number of votes each validator may cast is equivalent to the square root of their stake', while block production stays one-token-one-vote. Critically, NO NUMERIC THRESHOLD is published for consensus-connected chains such as Ethereum, only the qualitative description; the explicit 2-of-3 signing threshold in the deployment manifest applies to Amplifier-connected chains through their MultisigProver instances. Validators are required to rotate keys periodically, and each must run its own node for every source chain, with Axelar's own words: 'by querying the RPC endpoint of their source-chain node, validators can check if the submitted event was observed'. A containment control worth recording: 'The gateways have a rate limiting function, putting a cap on how much of each asset can be transferred in a given time interval.' Two things NOT established: any validator count more recent than the docs' self-dated 'as of August 2023' figure, and a numeric signing threshold for Ethereum.), composable with 4 other protocols. All nine scored categories are backed by verified evidence. Foreshock publishes the reading and the reasoning behind it. It is not a verdict on whether to use this protocol, and it is not investment advice.

Is Axelar safe?
Foreshock does not answer that as a yes or a no. Its independent reading of Axelar is Moderate risk, 35.0 out of 100, as of 7 September 2026, led by dependency risk: uses 1 oracle (Axelar IS the bridge, so the dependency question inverts: what it depends on is its own validator set and their independent chain nodes, and its own docs are unusually explicit about the trust model. The gateway on each chain 'is controlled by a key, which is held jointly by all Axelar validators', split into shares weighted by stake, and 'can only allow actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold'. Voting is quadratic for cross-chain validation: 'The number of votes each validator may cast is equivalent to the square root of their stake', while block production stays one-token-one-vote. Critically, NO NUMERIC THRESHOLD is published for consensus-connected chains such as Ethereum, only the qualitative description; the explicit 2-of-3 signing threshold in the deployment manifest applies to Amplifier-connected chains through their MultisigProver instances. Validators are required to rotate keys periodically, and each must run its own node for every source chain, with Axelar's own words: 'by querying the RPC endpoint of their source-chain node, validators can check if the submitted event was observed'. A containment control worth recording: 'The gateways have a rate limiting function, putting a cap on how much of each asset can be transferred in a given time interval.' Two things NOT established: any validator count more recent than the docs' self-dated 'as of August 2023' figure, and a numeric signing threshold for Ethereum.), composable with 4 other protocols. The score and the reasoning are published in full so the reading can be checked rather than trusted.
Has Axelar been audited?
6 audits on record, most recent audit is 1-2 years old; the most recent audit found 0 High and 1 Medium severity issues. This reflects code quality at the time of that audit only, not a claim that these specific issues are still unresolved today. An audit describes the code at the time it was reviewed. It is not a statement that the protocol is safe today.
Who controls Axelar?
Admin key: 72h timelock in place, open source. Top 10 holders control 47.11%, adjusted figure may still include pooled custody (untagged exchanges, infrastructure contracts) due to tagging coverage limits; exclusions require positive identification.
Has Axelar been exploited before?
No known own or inherited incidents. Foreshock records an incident against a protocol whether it originated there or was inherited from something it depends on.
When was this Axelar assessment last updated?
7 September 2026. Readings are recomputed as evidence changes, and every category carries the date of the evidence behind it.
Score by categories
Dependency risk9.1

Uses 1 oracle (Axelar IS the bridge, so the dependency question inverts: what it depends on is its own validator set and their independent chain nodes, and its own docs are unusually explicit about the trust model. The gateway on each chain 'is controlled by a key, which is held jointly by all Axelar validators', split into shares weighted by stake, and 'can only allow actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold'. Voting is quadratic for cross-chain validation: 'The number of votes each validator may cast is equivalent to the square root of their stake', while block production stays one-token-one-vote. Critically, NO NUMERIC THRESHOLD is published for consensus-connected chains such as Ethereum, only the qualitative description; the explicit 2-of-3 signing threshold in the deployment manifest applies to Amplifier-connected chains through their MultisigProver instances. Validators are required to rotate keys periodically, and each must run its own node for every source chain, with Axelar's own words: 'by querying the RPC endpoint of their source-chain node, validators can check if the submitted event was observed'. A containment control worth recording: 'The gateways have a rate limiting function, putting a cap on how much of each asset can be transferred in a given time interval.' Two things NOT established: any validator count more recent than the docs' self-dated 'as of August 2023' figure, and a numeric signing threshold for Ethereum.), composable with 4 other protocols.

Audit profile7.1

6 audits on record, most recent audit is 1-2 years old; the most recent audit found 0 High and 1 Medium severity issues. This reflects code quality at the time of that audit only, not a claim that these specific issues are still unresolved today.

Governance attack surface5.1

Top 10 holders control 47.11%, adjusted figure may still include pooled custody (untagged exchanges, infrastructure contracts) due to tagging coverage limits; exclusions require positive identification.

TVL profile3.6

TVL change (11%) is within a stable range.

Code characteristics3.0

Admin key: 72h timelock in place, open source.

Historical incidents2.3

No known own or inherited incidents.

Team factors1.8

Doxxed team, track record: unknown.

Bug bounty1.5

Has a bug bounty program, hosted on Immunefi.

Protocol age1.5

1409 days live, past the ~1yr floor; treated the same as any older protocol, not scored progressively safer with more age.

Assets held (4)

Available with a plan. See pricing.

Dependencies (2)

Available with a plan. See pricing.

Incident history (0)

Available with a plan. See pricing.

Audit history (6)

Available with a plan. See pricing.

Also covered on Multi-Chain

This assessment follows Foreshock's published methodology. Exact category weights, scoring rules, thresholds, and aggregation logic are proprietary and not shown here. How to interpret this assessment

This reading will change.

This reading is fixed at the date above it, and it stays there. We keep re-scoring Axelar as the evidence moves, a new audit, a changed admin control, an incident, and this page is free to read and always will be. The updated reading is what a plan buys: you are told by email on the day it changes, instead of finding out the next time you happen to look.

Get told when this changesBrowse every protocol
Axelar risk score, audits and admin control · Foreshock