Axelar Network
Cosmos-SDK proof-of-stake L1 (chain ID axelar-dojo-1) providing cross-chain General Message Passing (GMP) and token bridging via EVM Gateway/GasService contracts deployed on ~60 EVM chains and additional non-EVM chains (80+ total). Validator-set weighted-quorum security model with quadratic voting (square-root of stake). Core governance via on-chain Cosmos x/gov; EVM-side governance relayed via custom InterchainGovernance (7-day delay) + custom 3-of-6 Multisig. Interchain Token Service (ITS) enables canonical multichain token deployment. Original protocol — not a fork. Bug bounty on Immunefi ($500k max). Developed by Interop Labs (Circle acquisition announced Dec 2025).
DeploymentsBNB Chain · $12.9M
01
Risk profile at a glance
0 red · 1 yellow · 12 green 02
Categories & evidence
184 factors · 13 categoriesCode & audits Green 15 25 of 25
RD-F-001 yellow Audit scope mismatch Axelar has 60+ audit reports from 13+ firms covering EVM gateway and Cosmos core (2021-2025). Most recent ITS audits within 365 days (Ackee 2025-01, NCC 2024-11). However, bytecode-to-commit-SHA match for the deployed Ethereum AxelarGateway impl (0x99B5FA03, compiled 0.8.9, deployed ~2022) was not independently confirmed in this session. Scope mismatch cannot be ruled out with certainty for the legacy gateway implementation; newer ITS and AmplifierGateway contracts have recent audits covering deployed versions. RD-F-003 yellow Resolved-without-proof findings Ackee 2022 audits (34 total findings across 4 engagements) and Code4rena 2023-07 (11 issues, 2 high, 9 medium) have been followed by multiple re-audits confirming remediation. No post-mortem evidence of a finding marked Resolved that remains unpatched in deployed code found. However, specific per-finding resolution verification against current deployed bytecode was not performed in this session for all historical findings, preventing a definitive green. RD-F-005 yellow Audit firm tier No Tier-1 firm (Trail of Bits, OpenZeppelin, ConsenSys Diligence, Certora, Sigma Prime, Spearbit, Zellic) confirmed engaging Axelar. Tier-2 firms confirmed: NCC Group (established, public track record), Ackee Blockchain (established), Halborn (established), Ottersec (established), FYEO, Code4rena competitive audits. Yellow (Tier-2 only, no Tier-1 engagement found). RD-F-006 yellow Audit-to-deploy gap For the legacy Ethereum AxelarGateway (deployed ~Feb 2022), Ackee Feb 2022 audit (commit c6f8c7c) predates or coincides with deploy within reasonable window. For newer contracts (ITS), recent 2024-2025 audits cover current implementations. Exact audit-sign-off-to-deploy day counts not computed for all engagements due to the volume of reports. Evidence insufficient to confirm all major deploys meet the 60-day green threshold; downgrade to yellow. RD-F-014 yellow Reentrancy guard on external-calling functions AxelarGateway implements CEI pattern (mark-as-executed-first) rather than nonReentrant modifier. Code4rena 2023-07 found a reentrancy HIGH in ITS expressReceiveTokenWithData, which was remediated; Ackee 2025-01 post-remediation confirms fix. Current gateway core uses mark-before-execute for reentrancy protection. Yellow: historical high finding since resolved, and custom CEI approach without explicit nonReentrant guard. RD-F-015 yellow ERC-777/1155/721 hook without reentrancy guard Code4rena 2023-07 found ERC-777 token exploitation as a HIGH finding in ITS cross-chain token transfer paths. Remediation confirmed in subsequent Ackee 2025-01 ITS audit. Yellow: historical high finding in ITS ERC-777 path since remediated; ongoing vigilance needed for new token type integrations. RD-F-016 yellow Divide-before-multiply pattern No published Slither divide-before-multiply scan results found for deployed EVM contracts. The gateway arithmetic primarily involves weight-based threshold checks rather than precision-sensitive decimal math. No audit finding flagged divide-before-multiply as an issue. Yellow due to absence of published programmatic evidence rather than confirmed finding; [?] inference. RD-F-017 yellow Mixed-decimals math without explicit scaling Code4rena 2023-07 flagged cross-chain decimal handling causing fund loss as a MEDIUM finding in the ITS. This was remediated; Ackee 2025-01 post-remediation ITS audit covers the fixed code. The gateway core itself (lock/unlock of native tokens) does not perform complex cross-decimal arithmetic. Yellow: historical medium finding since remediated. RD-F-023 yellow Constructor calls _disableInitializers() Axelar uses a custom proxy pattern (not OZ UUPS/Transparent) where the onlyProxy modifier in Implementation.sol provides equivalent protection to _disableInitializers(). The constructor of AxelarGateway does not call _disableInitializers(); neither does AxelarGasService or InterchainTokenService. The custom onlyProxy guard achieves similar protection but via a different mechanism. Yellow: functionally protected but deviates from the OZ recommended pattern which this factor measures. RD-F-024 yellow Code complexity vs audit coverage Code4rena 2024-08 covered 4,000 SLOC across 18 days (Amplifier + CosmWasm ITS Hub + ITS Solidity). The total Axelar EVM codebase is larger when including the legacy gateway, GMP SDK, and ITS. Multiple firms have reviewed the full codebase across 3+ years and 60+ engagements. Complexity is high given multi-chain architecture but audit coverage is extensive. Yellow: adequate coverage overall but high system complexity and multi-chain surface prevents a definitive green. RD-F-009 gray Formal verification coverage No Certora, Kani, or Halmos formal verification engagement found for Axelar's gateway or AxelarAuthWeighted signature verification. Informal Systems 2023-04 performed a code audit (not a prover-based FV pass) of Cosmos GMP. Web search returned no Certora Axelar report. FV coverage for the critical AxelarAuthWeighted threshold/signature path is unconfirmed. RD-F-010 gray Static-analyzer high-severity count Slither/Mythril cannot parse the Cosmos-SDK Go core (axelar-core). For the EVM gateway (axelar-cgp-solidity), no published Slither scan output found. Factor requires programmatic tool run on Etherscan-verified source. Gap: [?] needs tool run for EVM-side Slither scan on 0x99B5FA03. RD-F-020 n/a EIP-712 domain separator missing chainId AxelarGateway uses a custom non-EIP-712 signing scheme for cross-chain command verification. The gateway message format uses ecrecover on a custom message format where chain binding is enforced at the Axelar consensus layer, not via EIP-712 chainId in a domain separator. No EIP-712 DOMAIN_SEPARATOR pattern found in deployed core contracts. This factor is structurally not applicable to Axelar's custom command-signing architecture.
RD-F-002 green Audit recency Most recent audit covering EVM contracts: Ackee Blockchain ITS (January 2025, ~4.5 months before assessment date 2026-05-17). NCC Group ITS audit November 2024 (~6 months). Multiple 2025 audits (Ackee Solana 2025-04, NCC XRPL 2025-01/02/04, FYEO Stacks 2025-02) confirm continuous active review cadence well within 365-day green threshold.
RD-F-004 green Audit count 13+ distinct audit firms confirmed from the audits repository README: Commonprefix, Cure53, Ackee Blockchain (18+ engagements), CertiK, Chaintroopers, NCC Group (6+ engagements), Informal Systems, Code4rena (2 competitive audits), Least Authority, Halborn, Ottersec, FYEO, Arda, Yaar Hahn. Far exceeds the 2-firm green threshold.
RD-F-007 green Bug bounty presence & max payout Active Immunefi bug bounty program confirmed with maximum payout of $500,000 (critical). Program live since 2022-03-11, last updated 2026-03-09. Covers 22 in-scope assets across 18 chains. $500k max payout meets the green threshold (>=$500K).
RD-F-008 green Ignored bounty disclosure No evidence found that a disclosed vulnerability was ignored by Axelar before exploit. The 2024 validator deregistration disclosure resulted in a $50,000 bounty payment and remediation via governance proposal 256. No Rekt.news incidents or post-mortems indicating ignored disclosures.
RD-F-011 green SELFDESTRUCT reachable from non-admin path AxelarGateway.sol contains depositHandler.destroy() calling selfdestruct on the ephemeral DepositHandler, which is deployed and destroyed in the same transaction (CREATE2 pattern, EIP-6780 compatible). DepositHandler destroy() is owner-restricted (onlyOwner). The gateway implementation itself has no SELFDESTRUCT reachable from non-admin paths. No SELFDESTRUCT in core path.
RD-F-012 green delegatecall with user-controlled target AxelarGateway.sol: the only delegatecall uses tokenDeployer (immutable, set in constructor) as target, not user-supplied. Upgradable.sol upgrade delegatecall is gated by onlyOwner plus code-hash and contractId identity checks. No user-controlled delegatecall target in EVM gateway contracts.
RD-F-013 green Arbitrary call with user-controlled target AxelarGateway execute function dispatches calls to addresses derived from validator-signed command data validated through the AxelarAuthWeighted proof system. Targets are not freely user-supplied without validator-quorum authorization. No direct arbitrary .call(user-target, user-data) pattern identified in EVM gateway.
RD-F-018 green Signed/unsigned arithmetic confusion Solidity 0.8.x enforces overflow/underflow protection by default (reverts on both). EVM contracts use 0.8.0+ (AxelarGateway) and 0.8.23 (GasService) and 0.8.19 (InterchainGovernance). ECDSA library uses standard uint8/bytes32 patterns. No signed/unsigned confusion finding in any of 13+ audit firm engagements.
RD-F-019 green ecrecover zero-address return unchecked The axelar-gmp-sdk-solidity ECDSA library explicitly checks: if (signer == address(0)) revert InvalidSignature(); after calling ecrecover. AxelarAuthWeighted uses ECDSA.recover() which includes this guard. The Wormhole-class vulnerability (unchecked ecrecover return) is explicitly mitigated.
RD-F-021 green UUPS _authorizeUpgrade correctly permissioned AxelarGateway does not use the UUPS pattern; no _authorizeUpgrade function exists. Custom proxy upgrade is gated by onlyGovernance. The Upgradable.sol base restricts upgrade() to onlyOwner with contractId and code-hash validation. No open or permissionless upgrade path found.
RD-F-022 green Public initialize() without initializer modifier AxelarGateway does not expose a standard initialize() function. Instead it uses setup(bytes) gated by onlyProxy modifier in Implementation.sol (reverts if implementationAddress == address(this), preventing direct-impl calls). The ITS proxy uses InterchainProxy with a custom setup gate. No unprotected initialize() on any core implementation contract. One-tx exploit via public initialize() is not possible.
RD-F-183 green Bug bounty scope gap on highest-TVL contracts Immunefi program covers 22 assets in scope across 18 chains. The highest-TVL contracts - AxelarGateway Ethereum proxy (~$51.6M) and ITS proxy - are the primary bridge surface and appear within scope. No explicit exclusion of core gateway contracts identified. $500k max payout (green threshold). The bounty scope excludes issues already in public GitHub issues (reasonable exclusion, not a scope gap). The 2024 validator deregistration bug was paid $50k, confirming whitehats can receive bounties for gateway-impacting issues.
Governance & admin Yellow 23 24 of 24
RD-F-027 red Single admin EOA [★ CRITICAL] 0x6f24A47Fc8AE5441Eb47EFfC3665e70e69Ac3F05 confirmed bare EOA (Etherscan: no contract code, no bytecode, compiler=-NA-). This EOA is the sole proxy admin/owner of the InterchainTokenService (ITS) proxy (0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C). It directly called upgrade() on ITS without any multisig relay or timelock in Jul 2025 (tx 0x59a8471b..., block 22,884,224) and Feb 2025 (tx 0x630d798e..., block 21,897,945). The Upgradable.sol base contract upgrade() function is onlyOwner with no delay. This EOA also holds setPauseStatus(), setTrustedChain(), removeTrustedChain(), and migrateInterchainToken() on ITS. The AxelarGateway's strong governance (validator quorum + 7-day timelock) does NOT extend to ITS — these are separate trust domains. A single private key compromise allows immediate, no-timelock ITS implementation replacement. Prior assessment scored green based on the gateway surface; U18 resolution confirms red on the ITS surface. RD-F-025 yellow Admin key custody type EVM gateway governance routes through validator-set quorum (AxelarGatewayProxyMultisig) and the InterchainGovernance contract (7-day minimum timelock). Operator/mintLimiter role held by custom 3-of-6 Multisig contract. ITS proxy upgrade authority held by bare EOA 0x6f24A47Fc8AE5441Eb47EFfC3665e70e69Ac3F05 (confirmed no contract code). Two distinct trust domains: gateway (strong) and ITS (bare EOA). Updated yellow from green to reflect split architecture. RD-F-026 yellow Upgrade multisig signer configuration (M/N) Gateway upgrades require Cosmos governance (≥2/3 validator quorum by quadratic-weighted stake) relayed through InterchainGovernance. Operator role: custom Multisig 3-of-6 (threshold=3, owners=6). ITS upgrades: single bare EOA (0x6f24...) directly calls upgrade() — no multisig. Two-tier architecture: strong on gateway, absent on ITS surface. Not a Gnosis Safe for any surface. RD-F-028 yellow Low-threshold multisig vs TVL Custom Multisig for operator/mintLimiter functions: 3-of-6 threshold for $144M TVS. Peer norm for $100M+ TVL is ≥4-of-7. 3-of-6 is below peer norm. All 6 signer addresses unattested — no public identity confirmations. Gateway upgrade path uses validator-quorum (much stronger). ITS surface has single bare EOA (worse than low-threshold multisig, captured by RD-F-027 red). RD-F-031 yellow Signer rotation recency Custom Multisig signerEpoch=3 indicating 3 signer-set rotations since October 2023 deploy. Most recent rotation date not precisely determined from available data. No threshold reduction event (from higher to lower) identified. Epoch progression indicates routine rotations occurred but timing not confirmed within 14-day window of timelock changes. RD-F-033 yellow Timelock on sensitive actions Upgrade (gateway): timelocked via InterchainGovernance 7-day. ITS upgrade: NO timelock (EOA direct call). Mint-limit setting (setTokenMintLimits): callable by Multisig without timelock. Pause: no traditional gateway pause; ITS setPauseStatus() callable by single EOA without timelock. setOracle: N/A. The 7-day timelock covers gateway upgrades but not ITS upgrades or all sensitive operational functions. RD-F-034 yellow Guardian/pause-keeper distinct from upgrader No explicit pause/guardian role on EVM gateway. mintLimiter (Custom Multisig 3-of-6) can set per-token rate caps — emergency defense, separate from upgrade path (good). ITS: single EOA holds both upgrade and setPauseStatus() — upgrader = pauser on the ITS surface (bad; collapse of separation). Partial separation on gateway; none on ITS. RD-F-039 yellow delegatecall/call in proposal execution without allowlist InterchainGovernance executeProposal(address target, bytes callData, uint256 nativeValue) uses external call (NOT delegatecall) on proposal-supplied target. No target allowlist — only check is if (target == address(0)) revert. Unconstrained arbitrary call after 7-day timelock + validator quorum passage. Mitigating factors: (1) call not delegatecall limits proxy-storage-manipulation exploit class; (2) 7-day observation window; (3) ≥2/3 validator quorum required. RD-F-040 yellow Emergency-veto multisig present No independent emergency-veto multisig can cancel arbitrary proposals. CancelTimeLockProposal command requires a new Cosmos governance vote (≥2/3 validator quorum) to cancel a queued proposal. This is the cancellation path — it exists but requires the same high-bar consensus as proposal creation, not a faster independent guardian. RD-F-041 yellow Rescue/emergencyWithdraw without timelock AxelarGateway has NO rescue/emergencyWithdraw/sweep function (confirmed from source). InterchainGovernance withdraw() is onlySelf — callable only through internal proposal execution after 7-day timelock. Residual risk 1: Custom Multisig (0xCC94...EC68) withdraw() can send ETH/tokens held by the Multisig contract (3-of-6, no timelock). Residual risk 2: ITS setPauseStatus(bool) callable by single EOA (0x6f24...) without timelock — can immediately halt ITS operations. Not a full TVL-drain function but operationally material. RD-F-042 yellow Admin has mint() with unlimited max Gateway mints bridged wrapped tokens via validator-set authorized commands (≥2/3 quorum). setTokenMintLimits() callable by mintLimiter (Multisig 3-of-6, no additional timelock) to set per-token per-6h transfer caps. The mint authority is the validator quorum (strong), but the Multisig can reset mintLimits to any value without timelock. No traditional admin-only mint(uint256) function found on ITS or gateway. mintLimits act as a secondary circuit breaker that the Multisig can adjust. RD-F-045 yellow Constructor args match governance proposal InterchainGovernance constructor args (gateway=0x4F44..., governanceChain=Axelarnet, governanceAddress=axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj, minimumTimeDelay=604800) verified on Etherscan and match Axelar's declared governance architecture. No specific governance proposal text found for cross-reference of exact deploy parameters. Minor gap. RD-F-029 gray Multisig signers co-hosted 6 multisig signer addresses (0x3f58..., 0x9256..., 0x1486..., 0x2eC9..., 0xf505..., 0x027c...) have no publicly attested identities, custodians, or infrastructure affiliations. Cannot assess co-hosting status. Cluster feed not queried. RD-F-030 gray Hot-wallet signer flag 6 multisig signer addresses have insufficient assessed signing history for hot-wallet behavioral heuristics. Signer tx patterns not evaluated in this session. RD-F-044 gray Admin wallet interacts with flagged addresses Admin/multisig signer addresses and ITS EOA 0x6f24... not assessed against flagged address watchlists in this session. Cluster feed not queried. 6 Multisig signers (0x3f58..., 0x9256..., 0x1486..., 0x2eC9..., 0xf505..., 0x027c...) and EOA 0x6f24... are the relevant addresses. RD-F-047 gray Governance token concentration (Gini) AXL governance token holder Gini not computed in this session. Axelar uses quadratic weighting (square root of stake) for validator voting power which partially mitigates concentration vs linear-weighted systems. Full token-holder Gini and top-10 share require on-chain scan not performed here.
RD-F-032 green Timelock duration on upgrades InterchainGovernance minimumTimeLockDelay = 604,800 seconds = 168 hours = 7 days. Verified on-chain from readContract. This is the EVM timelock-equivalent for gateway/governance upgrades. Well above the 48-hour green threshold. CAVEAT: this timelock applies to the gateway upgrade path only. ITS upgrades have NO timelock (direct EOA call — see F027).
RD-F-035 green Role separation: upgrade ≠ fee ≠ oracle Role separation confirmed on gateway: upgrade role = InterchainGovernance (validator quorum); mintLimiter = Custom Multisig 0xCC94...EC68; GasService collector = Operators 0x7DdB... (owner 0x6f24...). ITS: most roles collapse into single EOA 0x6f24... (upgrade, pause, trusted-chain), but GasService and Operators are separate contracts from the custom Multisig. Overall role distribution across contracts is separated even if ITS intracontract roles are concentrated.
RD-F-036 green Flash-loanable voting weight Axelar uses Cosmos-SDK x/gov. Voting weight is staked AXL on Cosmos chain with ~21-day unbonding period. AXL staking is NOT flash-loanable (Cosmos PoS, not EVM token balance). Cross-chain gateway commands require ≥2/3 of validators by quadratic-weighted stake — not vulnerable to EVM flash loans. Structurally immune to Beanstalk-class attack.
RD-F-037 green Quorum achievable via single-entity flash loan Cosmos governance quorum requires ≥2/3 of approximately 75 active validators by quadratic-weighted stake. Single-entity flash loan on EVM cannot obtain Cosmos-staked AXL position. Even on-chain AXL acquisition and staking requires 21-day bonding. Flash-loan-based quorum achievement is structurally impossible.
RD-F-038 green Proposal execution delay < 24h Total delay for gateway EVM execution: Cosmos voting period (~72 hours = 3 days) + InterchainGovernance 7-day timelock = minimum ~10 days. Well above the 48-hour green threshold. ITS upgrades have 0-day delay (EOA direct call) — but this factor scores the gateway governance path; ITS centralization is captured by F027.
RD-F-043 green Admin = deployer EOA after 7 days AxelarGateway proxy deployed ~January 2022 by Axelar: Deployer (0xa57adce1d2fe72949e4308867d894cd7e7de0ef2). Current gateway governance held by InterchainGovernance + validator-quorum contract. Deployer EOA has no retained gateway admin role 4+ years post-deploy. ITS admin (0x6f24A47Fc8AE5441Eb47EFfC3665e70e69Ac3F05) is the ITS creator/deployer address but this is a separate operational address from the gateway deployer — F043 measures gateway-deployer-EOA retention specifically. ITS EOA centralization is the F027 red finding.
RD-F-046 green Contract unverified on Etherscan/Sourcify All core EVM contracts verified on Etherscan with public source and ABI: AxelarGateway proxy (0x4F44...D56A5), implementation (0x99B5...94098), InterchainGovernance (0xfDF3...476a66), Custom Multisig (0xCC94...EC68), Operators (0x7DdB...4CeefbC), GasService (0x2d5d...2712), InterchainTokenService proxy (0xB5FB...3C). All verified at launch.
RD-F-167 green Deprecated contract paused but pause reversible by live admin No deprecated Axelar EVM contracts holding material value identified. The AxelarGatewayProxyMultisig is the current live system (not deprecated). InterchainTokenService v1 deprecation status not confirmed but no material orphaned TVL in old addresses observed. Profile does not flag any deprecated contracts with funds.
Oracle & external dependencies Green 9 17 of 17
RD-F-050 yellow Dependency graph (protocols depended upon) Axelar's primary existential dependency is its own Cosmos-SDK L1 validator set (~47 active validators, 60% weighted quorum for cross-chain operations). Secondary dependencies: AxelarAuthWeighted auth module for proof validation, InterchainGovernance (7-day delay) for EVM parameter changes, custom 3-of-6 Multisig as mintLimiter. No external third-party DeFi protocol dependency for bridge function. Yellow because the validator set is a non-redundant single trust root — chain halt causes full bridge halt with no fallback. RD-F-051 yellow Fallback behavior on oracle failure No traditional oracle fallback design (no price oracle used). For validator-set failure: if quorum drops below 60% threshold for cross-chain signing, bridge operations halt with no graceful degradation or fallback source. The mintLimiter (3-of-6 Multisig) provides a rate-limit backstop capping per-epoch mints even under partial validator compromise, but this is a damage-limitation measure, not a fallback source for cross-chain verification. RD-F-052 yellow Breakage analysis per dependency Breakage analysis: (1) Cosmos chain halt — all bridge ops stop; source-chain gateway funds locked until chain recovers; no estimated recovery timeline. (2) Validator compromise above 40% weighted quorum — forged commands possible; mintLimiter rate-limits per-epoch damage to configured per-symbol caps. (3) Custom 3-of-6 Multisig compromise — mintLimiter reconfigurable, rate limits can be disabled or bypassed. (4) InterchainGovernance failure — EVM-side parameter updates blocked; 7-day delay acts as safe default; Cosmos governance still functional. (5) Auth module bug in AxelarAuthWeighted — proof validation fails or is bypassed; full bridge fund risk for locked TVL ($144.73M). Yellow because validator-set compromise scenario has meaningful (though non-trivial) attack complexity. RD-F-057 yellow Circuit breaker on price deviation No price-deviation circuit breaker (no price oracle). However, the mintLimiter (per-symbol, per-6-hour-epoch cap) functions as a volume-based rate-limit circuit breaker on token minting. Yellow because while no price circuit breaker exists, the volume cap provides meaningful damage limitation for a bridge exploit scenario, but it is a volume cap not a price-anomaly detector. RD-F-058 gray Max-deviation threshold (bps) No price-deviation threshold (no price oracle). Per-symbol mint limit values configured in AxelarGateway are not publicly enumerated in a single accessible reference; exact values require on-chain reads via getTokenMintLimits() per symbol. Not extracted in this session. RD-F-181 n/a Permissionless-pool lending oracle Axelar is a bridge/GMP protocol, not a lending protocol. F181 (permissionless-pool lending oracle / isolation-tier config) applies to lending protocols that accept spot prices from permissionless DEX pools as collateral oracle. No such lending oracle pattern exists in Axelar's bridge architecture. Data cache confirms lending_protocol: false.
RD-F-048 green Oracle providers used Axelar's bridge function uses NO traditional price oracle. The trust root is the Cosmos-SDK PoS validator set. Source inspection of AxelarGateway.sol and AxelarGasService.sol confirms no latestAnswer(), latestRoundData(), or equivalent oracle call. The 19 Chainlink feed addresses in the data cache are peripheral (third-party integrators using Axelar GMP, not consumed by Axelar's own contracts).
RD-F-049 green Oracle role per asset No price oracle feeds used in primary/secondary/fallback role for bridge value. The oracle equivalent is the validator-set consensus on the Axelar Cosmos chain. Profile §7 explicitly states bridge function does not rely on price oracles in the traditional DeFi sense.
RD-F-053 green Oracle source = spot DEX pool (no TWAP) [★ CRITICAL] Bridge value path is validator-set consensus, NOT DEX-priced spot oracle. AxelarGateway.sol contains no oracle call — authentication is delegated to IAxelarAuth(authModule).validateProof(messageHash, proof) which is the validator-weighted signature check. AxelarGasService.sol gas payment is msg.value-based with no oracle-priced valuation. The 19 Chainlink feeds in data cache are peripheral/integrator-side and NOT consumed by Axelar's gateway contracts. Spot DEX oracle attack vector is not present in the bridge architecture.
RD-F-054 green TWAP window duration No TWAP oracle used by the bridge function. Factor is not applicable to Axelar's validator-consensus architecture. Scored green (not not_applicable) as the bridge is active and the absence of a TWAP dependency is a positive security property.
RD-F-055 green Oracle pool depth (USD) No DEX pool oracle used. Bridge value verification is via validator-set consensus. Oracle pool depth is not a relevant attack surface for this architecture.
RD-F-056 green Single-pool oracle (no medianization) No pool-based oracle used. Single-pool / medianization question is not applicable to the validator-consensus architecture.
RD-F-059 green Oracle staleness check present No time-sensitive price oracle consumed by the bridge function. Validator-set consensus has liveness requirements at the Cosmos chain level (epoch finality). The staleness-check factor is not applicable to the validator-consensus trust model.
RD-F-060 green Chainlink aggregator min/max bound misconfig Axelar's gateway contracts do not consume Chainlink aggregator output for value-securing decisions. The 19 Chainlink feeds in the data cache are peripheral (integrator-side). Chainlink min/max bound misconfiguration is not a risk surface for Axelar's own contracts.
RD-F-061 green LP token balanceOf used for pricing No LP token balanceOf-based pricing used. Bridge value verification is via validator-set consensus, not token balance reads.
RD-F-062 green External keeper/relayer not redundant Axelar's validator set (~47 active validators) collectively serves the keeper/relayer function for message signing. No single validator is a required keeper. Multiple independent relayers operate in Axelar's ecosystem for GasService fulfillment. The quadratic weighting and PoS staking model provide structural redundancy beyond a single keeper dependency.
RD-F-180 green Immutable oracle address [★ CRITICAL-CANDIDATE — PD-017 held] F180 tests whether a lending oracle address is immutable, preventing repricing when an asset depegs. Axelar is a bridge, not a lending protocol. No repricing oracle is used. The auth module address (AxelarAuthWeighted) IS replaceable via governance: InterchainGovernance (7-day delay) relays Cosmos x/gov proposals to EVM; the gateway's authModule can be updated. The F180 failure mode (oracle-address immutability trapping a lending protocol post-depeg) does not apply to bridge architecture. Scored green; flag to orchestrator per PD-017 tracking.
Economic risk Green 17 13 of 13
RD-F-064 yellow TVL concentration (top-10 wallet share) Single-chain concentration: Ethereum holds 89.23% of total TVS ($129.15M of $144.73M). BSC is the only material secondary at 8.94% ($12.94M). Within the Ethereum gateway (0x4F4495243837681061C4743b74B3eEdf548D56A5), the ZIG gaming token constitutes ~$18.81M (~37% of gateway by USD), making it the single largest holding by USD value ahead of USDC ($14.71M). ZIG is a low-liquidity gaming token (Zignaly), representing material single-token concentration risk within the escrow. Validator stake: top-10 validators hold ~40% of raw AXL stake [?] (secondary source); quadratic voting (weight = sqrt(stake)) dampens effective voting concentration but exact quadratic share not computed. Yellow rather than red because: (a) Ethereum dominance is structurally normal for a bridge (not pathological); (b) quadratic voting mitigates raw stake concentration; (c) ZIG finding is surprising but total TVS effect is bounded. RD-F-065 gray Liquidity depth per major asset Bridge liquidity depth cannot be assessed via DEX subgraph (Dune Analytics 403; no direct subgraph for Axelar-wrapped asset pools retrieved). mintLimiter rate caps on major assets (USDC, FRAX, ETH per security docs) exist but specific numerical limits are undisclosed. axlUSDC is the most liquid axl-wrapped asset; axlWBTC and axlWETH exit liquidity depends primarily on bridge-back, not secondary markets. ZIG (~$18.81M in gateway) has thin secondary market liquidity. Without DEX depth data, this factor cannot be reliably graded. Gap documented: Dune 403 is a universal structural barrier per process-learnings. RD-F-066 n/a Utilization rate (lending protocols) Lending-only factor (utilization rate). Axelar is a cross-chain bridge protocol with no lending or borrow surface. Data cache confirms borrow.present=false. PD-024 directs not_applicable for non-lending protocols. RD-F-067 n/a Historical bad-debt events Lending-only factor (bad debt events). Axelar has no lending protocol surface; bad debt is structurally inapplicable. PD-024 directs not_applicable for non-lending protocols. RD-F-068 n/a Collateralization under stress Lending-only factor (collateralization ratio). Axelar operates a lock-and-mint bridge model with no collateral/borrow mechanism. PD-024 directs not_applicable for non-lending protocols. RD-F-069 n/a Algorithmic / under-collateralized stablecoin Factor applies to algorithmic/under-collateralized stablecoin issuers. Axelar does not issue a stablecoin. AXL is a PoS staking/gas token. axlUSDC and axlUSDT are wrapped/bridged representations backed 1:1 by locked assets in the gateway escrow — not algorithmic designs. PD-024 directs not_applicable for non-stablecoin-issuer protocols. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) Critical factor — empty cToken-style market (Compound V2 fork exploit pattern). Axelar is not a Compound V2 fork. It is an original Cosmos-SDK PoS L1 + EVM gateway bridge protocol with no cToken markets, no lending mechanics, and no share-based vault accounting. The taxonomy Cat 4 PD-024 note explicitly states: 'Compound-fork-only (subset of lending-only): RD-F-070 — N/A for non-Compound-fork protocols.' Data cache borrow.present=false. No ERC-4626, no cToken, no share inflation attack surface exists in the Axelar gateway architecture. RD-F-071 n/a Seed-deposit requirement for new market listing Lending-only factor (seed-deposit requirement for new-market listing). Axelar has no market-listing governance mechanism. PD-024 directs not_applicable for non-lending protocols. RD-F-072 n/a Market-listing governance threshold Lending-only factor (market-listing governance threshold). Axelar has no permissioned or governance-gated market-listing mechanism. PD-024 directs not_applicable for non-lending protocols. RD-F-073 n/a Oracle-manipulation-proof borrow cap Lending-only factor (oracle-manipulation-proof borrow cap). Axelar has no borrow cap mechanism. Data cache borrow.present=false. PD-024 directs not_applicable for non-lending protocols. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) Factor requires ERC-4626 vault accounting. The AxelarGateway and InterchainTokenService do not implement ERC-4626. The gateway uses a lock-and-mint model with validator-consensus proof for cross-chain transfers. No share-based vault mechanism exists in the Axelar EVM contract set. RD-F-075 n/a First-depositor / share-inflation guard Factor requires share-based vault with first-depositor attack surface (ERC-4626 or cToken-style). Axelar uses lock-and-mint bridge semantics — no share/token minting against deposited value, no first-depositor mechanics. PD-024 applies; architecture confirms absence of share-inflation attack surface.
RD-F-063 green TVL (current + 30d trend) TVL $144.73M as of 2026-05-16 (DefiLlama API). 30-day change +3.18%; 90-day CoV 2.22% (mean $141.43M, std $3.14M, 90 samples). TVL is stable with slight upward drift. Well above $100M coverage threshold. All-time peak ~$613M (Dec 2023 [?]), representing a secular drawdown from bridge-market peak but current level is stable.
Operational history Green 4 15 of 15
RD-F-087 yellow Pause > 7 consecutive days Axelar's Cosmos chain (axelar-dojo-1) undergoes governance-coordinated upgrade halts inherent to Cosmos SDK appchains. These are planned operational events, not exploits. No confirmed >7-consecutive-day halt found in last 12 months; however, axelarscan.io block explorer returned non-parseable response for block timestamp lookup, so precise halt durations cannot be confirmed from on-chain data. Scored yellow conservatively: liveness is a known risk axis for this architecture (2024 disclosure demonstrated forced-deregistration-triggered halt vector; that vector resolved but halt risk remains structural), and halt duration data is unconfirmed. RD-F-089 yellow Insurance coverage active No active third-party insurance coverage found on Nexus Mutual, Unslashed, Sherlock, or equivalent for Axelar gateway contracts. Web search for Axelar + Nexus Mutual returned no coverage policy. Structural near-default for cross-chain bridges at this TVL scale ($144M). Protocol mitigates via on-chain rate limiters (per-asset transfer caps per time window) documented in security docs, but no external insurance cover confirmed.
RD-F-076 green Protocol age (days) Axelar mainnet launched February 2022 (Ethereum AxelarGatewayProxyMultisig 0x4F4495... deployed ~January/February 2022). As of 2026-05-17 this is approximately 1,566 days (~51 months) of live operation, well above any 12-month A-grade eligibility threshold.
RD-F-077 green Prior exploit count Zero confirmed exploits with fund loss against Axelar's own protocol. Proprietary hacksdatabase search (190 entries) returned no Axelar-protocol exploit files. data-cache rekt.incidents=[] and defillama.hacks=[]. REKT News web search found no Axelar exploit writeup. The GNUS.AI May 2024 incident involved a compromised GNUS team private key and Axelar's bridge operated as designed; Axelar gateway security was not breached.
RD-F-078 green Chronic-exploit flag (≥3 incidents) Zero confirmed exploits. Chronic flag (>=3 prior exploits) does not apply. Same sources as F077.
RD-F-079 green Same-root-cause repeat exploit No prior exploits; same-root-cause repeat exploit factor does not apply. Zero confirmed incidents in hacksdatabase, REKT, and DefiLlama hacks.
RD-F-080 green Days since last exploit No prior exploits. Days-since-last-exploit resolves favorably: no exploit has occurred across ~51 months of mainnet operation.
RD-F-081 green Post-exploit response score No exploits occurred; no post-exploit response score required. The 2024 responsible disclosure demonstrates positive process: team classified the bug as Critical, resolved via governance proposal 256 over ~5 months, paid $50,000 USDC bounty. The response was coordinated and transparent in outcome, though slow in timeline (acceptable given governance-required fix).
RD-F-082 green Post-mortem published within 30 days No exploits occurred; no post-mortem required. Public researcher writeup on the 2024 responsible disclosure constitutes a de-facto public disclosure document. No incidents for which a post-mortem was due but not published.
RD-F-083 green Auditor re-engaged after last exploit No exploits requiring auditor re-engagement occurred. Protocol maintains continuous active audit engagement: 60+ reports, most recent from Ackee Blockchain (through 2025-08), NCC Group (2025-04), Ottersec (2025-04), Arda (2025-04). Ongoing audit coverage without incident-driven gap.
RD-F-084 green TVL stability (CoV over 90d) TVL stability is good. data-cache tvl_30d_change_pct=+3.18%, tvl_1d_change_pct=-0.21%. 90-day mean per profile is $141.4M vs current $144.7M, indicating low coefficient of variation. No sudden drawdowns in recent history suggesting operational distress or team dysfunction.
RD-F-085 green Incident response time (minutes) No exploits with fund loss occurred; incident response time factor is N/A in the positive direction. The 2024 responsible disclosure was private and coordinated with no active-exploit emergency response required.
RD-F-086 green Pause activations (trailing 12 months) No emergency-stop activations found in the trailing 12 months. Axelar's Cosmos chain undergoes scheduled governance-coordinated upgrade halts (normal Cosmos SDK appchain operations, not security pauses). Rate limiters on EVM gateways are a structural control, not a pause event. No evidence of security-driven pause activation in 2025-05 to 2026-05 window.
RD-F-088 green Re-deployed to new addresses in last year No evidence of redeployment to new contract addresses in last 12 months. Axelar uses a proxy upgrade pattern on EVM (same proxy address 0x4F4495243837681061C4743b74B3eEdf548D56A5 retained across implementation upgrades). Gateway contract addresses on all supported chains are stable per the mainnet config. No mass-redeployment or address migration event found.
RD-F-166 green Deprecated contracts still holding value No officially-deprecated Axelar contracts identified holding material value (>$100k). Axelar uses a proxy upgrade pattern retaining stable proxy addresses across implementation upgrades — deprecated implementations leave no residual locked TVL at orphaned addresses. No prior gateway address found that was sunsetted and replaced at a new address with stuck user funds. Mainnet.json shows a single active gateway per chain.
Real-time signals Green 0 22 of 22
RD-F-090 gray Mixer withdrawal → protocol interaction T-09 phase-2 signal. Applicable: bridge is a passive-venue conduit; mixer-funded wallets interacting with Axelar gateways is a real risk class. Structural passive-venue routing confirmed by GNUS.AI 2024 exploit (attacker bridged counterfeit tokens via Axelar — U4 PASSIVE-VENUE, not team contamination). No licensed wallet-clustering attribution feed wired in this assessment; public-proxy observation finds no confirmed mixer-to-gateway interaction targeting Axelar's own contracts. RD-F-099 n/a Oracle price deviation >X% from secondary Axelar's bridge verification relies on validator-set quorum consensus (Cosmos-SDK proof-of-stake), not on on-chain price oracles. Oracle price deviation does not affect gateway message verification or bridge security. The 19 Chainlink feed addresses in the data cache are assessed as peripheral (GasService fee estimation or integrator-side use) rather than core security inputs. Confirmation of peripheral status is flagged for oracle-dependency-analyst; if any feed is confirmed as a core security input this factor should be re-evaluated. RD-F-100 n/a Flash loan >$10M targeting protocol tokens Flash-loan attacks target oracle manipulation or governance quorum manipulation. Axelar's bridge verification is validator-quorum based (Cosmos PoS); flash loans cannot manipulate the multisig signing or Cosmos consensus quorum. The signal is not applicable to the core bridge security path. Applicable only to peripheral interactions (GasService fee manipulation) which do not threaten TVL. T-09 phase-2 signal even for applicable protocols. RD-F-102 gray Admin/upgrade transaction in mempool T-09 phase-2 signal. EVM-side admin transactions via InterchainGovernance and custom Multisig (0xCC940AE49C78F20E3F13F3cF37e996b98Ac3EC68) are monitorable in principle. Multisig last executed 2026-01-04 (executeContract x3, approximately 132 days before assessment date) — no recent admin or upgrade transaction detected. Cosmos-side admin transactions are non-EVM and not observable via standard EVM mempool tooling. Mempool listener stack not wired. RD-F-105 gray DNS/CDN/frontend hash drift T-09 phase-2 signal. Applicable: axelar.network, satellite.axelar.network (now squidrouter.com), and axelarscan.io are high-value brand surfaces. External hash-drift monitor not wired. No frontend incident or DNS hijack confirmed via public sources as of 2026-05-17. Note: satellite.axelar.network redirects to squidrouter.com (Squid Router, a separate entity) — change-management allowlist must track this migration. Baseline hash for JS bundle monitoring needs to be established. RD-F-107 n/a Admin EOA signing from new geography/device Off-chain signing telemetry not available via public tools for either Cosmos validators or EVM multisig signers. Cosmos core is non-EVM; device fingerprint analysis is not applicable to Cosmos validator signing. EVM multisig signers use a custom contract (not hardware wallet with MPC session keys). No MPC session-key providers expose device fingerprints publicly for this configuration. V2-deferred signal; data source structurally unavailable for this protocol architecture. RD-F-109 gray Social-media impersonation scam spike V2-deferred signal. Social-media impersonation monitor not wired. No confirmed scam-coordinator spike or fake airdrop campaign identified via targeted search as of 2026-05-17. Axelar has active X presence and Discord; brand impersonation risk is elevated for a $144M bridge but no active campaign confirmed. Requires social-listening vendor integration.
RD-F-091 green Partial-drain test transactions No partial-drain test transactions detected. TVL is $144.73M with a 30d change of +3.18% and 1d change of -0.21%. No anomalous small-value gateway outflow pattern fitting pre-strike reconnaissance observed via DefiLlama data. Axelar has zero confirmed exploit history against its own gateway contracts.
RD-F-092 green Unusual mempool pattern from deployer wallet No unusual mempool pattern from deployer wallet (0xa57adce1d2fe72949e4308867d894cd7e7de0ef2) identified. Deployer is labeled 'Axelar: Deployer' on Etherscan with clean funding history (AscendEX-sourced). V2-deferred signal; no public alert or anomaly reported. Cosmos-side deployer activity is non-EVM and not observable via standard mempool tooling.
RD-F-093 green Abnormal gas-price willingness from attacker wallet No abnormal gas-price willingness from attacker-labeled wallets detected against Axelar EVM gateways. V2-deferred signal; no mempool listener wired. No gas-racing pattern identified via public sources. Cosmos core is not covered by EVM gas-price signal (non-EVM substrate).
RD-F-094 green New contract with similar bytecode to exploit template No new contract deployment with high bytecode similarity to Axelar's gateway contracts (AxelarGateway, AxelarAuthWeighted) targeting this protocol identified. V2-deferred signal; no deploy-sweep tool wired. No public report of exploit-template copycat deployment against Axelar identified.
RD-F-095 green Known-exploit function-selector replay No known-exploit selector-pattern replay against Axelar EVM gateways identified. The primary Axelar exploit risk class is the ecrecover-weighted-multisig pattern (AxelarAuthWeighted); no in-the-wild selector-replay targeting this pattern found in public sources. V2-deferred signal.
RD-F-096 green New ERC-20 approval to unverified contract from whale No whale/high-TVL user approval to unverified contract interacting with Axelar detected. User-level signal; V2-deferred. Axelar's bridge architecture means user approvals are to the verified AxelarGateway contracts rather than unverified intermediaries in the core flow.
RD-F-097 green Sybil surge of identical-pattern transactions No sybil transaction surge pattern detected on Axelar gateway contracts. V2-deferred signal. Axelar's validator-quorum security model is not susceptible to sybil surges at the user transaction level; the attack surface for this signal is limited on Axelar's architecture.
RD-F-098 green TVL anomaly — % drop in <1h T-09 v1 launch signal. TVL $144.73M as of 2026-05-16; 30d rolling baseline approximately $141.4M (90d mean from data cache); current/baseline ratio = 1.023, well above the 0.70 threshold. 30d change +3.18%; 1d change -0.21%. No sector-wide TVL event detected. No pre-announced drain or migration. Signal would NOT fire today. Axelar has zero confirmed exploit-related TVL loss events in its history.
RD-F-101 green Large governance proposal queued T-09 v1 launch signal. Axelar has active Cosmos x/gov governance on axelar-dojo-1 and EVM relay via InterchainGovernance (0xfDF36A30070ea0241d69052ea85ff44Ad0476a66, 7-day minimum delay). Most recent notable governance proposal was #256 (2024, chain-halt vulnerability fix — legitimate security response, not malicious pattern). No malicious-pattern governance proposals identified as of 2026-05-17. The Cosmos governance model (AXL-staked validator voting) is not susceptible to flash-loan quorum attack — staked AXL is locked, not flash-loanable. EVM side has mandatory 7-day timelock. Signal would NOT fire today.
RD-F-103 green Bridge signer-set change proposed/executed T-09 v1 launch signal. Highly applicable: Axelar has two signer-set monitoring surfaces — (1) EVM custom Multisig 0xCC940AE49C78F20E3F13F3cF37e996b98Ac3EC68 (3-of-6 threshold); (2) Cosmos validator set changes on axelar-dojo-1. Multisig last transacted 2026-01-04 (executeContract, not a signer change). Threshold remains 3-of-6. No unscheduled signer change detected. Axelar docs confirm periodic key rotations are a declared scheduled protocol policy — these would be suppressed by the change-management allowlist. Signal would NOT fire today.
RD-F-104 green Stablecoin depeg >2% on shared-LP venue T-09 v1 launch signal. Partial applicability: Axelar bridges axlUSDC and has rate limits on USDC/FRAX/ETH per-window. Protocol exposure to stablecoin depeg is via wrapped tokens in gateway contracts, not lending collateral. Rate limiters structurally bound depeg-to-drain velocity. No stablecoin depeg active as of 2026-05-17. USDC and USDT stable. Signal would NOT fire today.
RD-F-106 green Cross-chain bridge unverified mint pattern No active mint-without-proof pattern detected on Axelar gateways. The GNUS.AI 2024 exploit involved an attacker who compromised the application-layer private key and used Axelar bridge as a passive conduit to move counterfeit tokens cross-chain — this was an exploit at the application layer (GNUS.AI token contract), not a compromise of Axelar's proof/consensus verification. No unverified-mint event against Axelar's own gateway security has been documented.
RD-F-108 green GitHub force-push to sensitive branch No GitHub force-push or sensitive-branch push from non-authorized account detected on axelarnetwork org repos (axelar-core, axelar-cgp-solidity). axelar-core v1.3.10 was the last release (2026-02-17). V2-deferred signal; no automated GitHub monitor wired. Public GitHub org shows no anomalous branch activity via available search.
RD-F-110 green Unusual pending/executed proposal ratio Unusual pending/executed governance proposal ratio not detected. Axelar's Cosmos x/gov module has a normal governance cadence; proposal 256 (chain-halt fix, 2024) is the most prominent recent proposal and was passed/executed. V2-deferred signal. No unusual backlog of pending proposals or abnormally high pending/executed ratio identified via public forum data as of 2026-05-17. EVM-side governance relay via InterchainGovernance also shows no queued proposal backlog.
RD-F-182 green Security-Council threshold reduction (RT) T-09 v1.1 candidate signal (not yet production-live). Security-Council threshold reduction signal. Applicable: Axelar's custom 3-of-6 EVM Multisig (0xCC940AE49C78F20E3F13F3cF37e996b98Ac3EC68) is the EVM gateway operator council. Any threshold reduction (3-of-6 to 2-of-6) or new-signer addition within 14 days of a threshold change would trigger. Directly analogous to Drift Apr 2026 pattern (3/5 to 2/5 + timelock removal preceding $285M DPRK exploit). Current posture: multisig last transacted 2026-01-04 (executeContract x3); threshold remains 3-of-6; no signer-change or threshold-reduction event detected in the trailing 14-day window. Signal would NOT fire today.
Dev identity & insider risk Green 7 16 of 16
RD-F-117 yellow ENS/NameStone identity bound to deployer No ENS or NameStone name found bound to the deployer address 0xa57adce1d2fe72949e4308867d894cd7e7de0ef2 or to any of the 6 EVM multisig signer addresses. Etherscan shows 'Axelar: Deployer' label (exchange-level label, not ENS-bound identity). Axelar does operate EVM contracts where ENS binding would be applicable; the team has simply not bound an ENS name. Yellow per rubric (deployer operates on EVM chains but no ENS identity bound). RD-F-119 yellow Commit timezone consistent with stated geography Recent axelar-core commits (Feb-Mar 2026) show contributors (jakovmitrovski, cgorenflo, themicp) with names and commit patterns qualitatively consistent with Eastern European / Canadian timezones. Common Prefix (successor developer post-Circle acquisition) is Greece-based, consistent with EU timezone. No anomalous DPRK-timezone (UTC+8/+9) clustering flagged. However, full quantitative commit-time distribution analysis was not performed — this requires GitHub API batch analysis not available in this session. Yellow due to incomplete quantitative analysis. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Two findings assessed: (1) Governance Proposal 256 (disabled Chain Maintainer auto-deregistration) — followed a 5-month Immunefi responsible-disclosure process; went through the public Cosmos x/gov vote. Not an unannounced admin rescue — clear prior disclosure trail. (2) EVM custom Multisig (0xCC940AE49C78F20E3F13F3cF37e996b98Ac3EC68): signerEpoch=3 at assessment date, meaning at least 2 signer rotations since Oct 2023 deployment. Public forum discussion corresponding to these EVM-side signer rotations was not located. Rate limits set via 'governed multisig' for emergency speed (per docs). Circle acquisition (Dec 2025) was fully disclosed publicly with successor developer (Common Prefix) named. The EVM multisig rotation documentation gap (not the Cosmos governance path) is the basis for yellow rather than green. RD-F-184 gray Real-capital social-engineering persona RD-F-184 (real-capital social-engineering persona with >=1M deposits to build credibility) is an M-only curator-flagged factor. No positive adversarial signal found: no anonymous high-capital depositor identified as attempting to gain team access; no Drift-style infiltration pattern detected. Axelar's founding team is fully doxxed academic figures with 4+ years of documented public presence, making this attack vector harder to execute. However, as an M-only factor, affirmative assessment requires curator surveillance — not determinable from open web search alone. Gray per gap_reason requires_curator_input. Comparator: Drift Protocol (UNC4736 deployed >$1M real capital over 6 months before exploit — this level of adversarial signal would require curator-confirmed attribution). No comparable signal found for Axelar.
RD-F-111 green Team doxx status Founders Sergey Gorbunov (MIT PhD, UWaterloo Assistant Professor, ex-Algorand founding team) and Georgios Vlachos (MIT MS/BS, IMO Gold Medal 2011, ex-Algorand Head of Math, Axelar Foundation Director) are fully doxxed with verified real names, academic affiliations, LinkedIn profiles, and extensive conference appearances. Post-acquisition, Gorbunov joined Circle; Vlachos remains at Axelar Foundation. Common Prefix (Greece-based firm) identified as continuity developer. Team doxx status: real-name with full institutional trail.
RD-F-112 green Team public accountability surface Both co-founders have deep verifiable public trails: Gorbunov has peer-reviewed publications at TCC 2020, CCS 2020, USENIX Security 2020, UWaterloo faculty page, multiple podcast/YouTube appearances, and participated in SEC meeting (June 2025). Vlachos appeared in person at Upbit D Conference 2024, Cosmoverse (Medellin), and CryptoNews podcast ep 387 (Nov 2024). GitHub contributors (jakovmitrovski, cgorenflo, themicp, chipshort) are publicly identifiable. Accountability surface is exceptionally high for a DeFi protocol.
RD-F-113 green Team other-protocol involvement history Both founders were founding team members at Algorand (a legitimate, major L1). No prior rug or exit-scam-labeled protocol affiliations found. Multiple explicit searches for 'Axelar rug exit scam fraud' and 'Sergey Gorbunov OR Georgios Vlachos exit scam prior protocol' yield zero adverse results. Scam results returned are third-party impersonators, not team-originated activity.
RD-F-114 green Deployer address prior on-chain history Deployer 0xa57adce1d2fe72949e4308867d894cd7e7de0ef2 is labeled 'Axelar: Deployer' on both Etherscan and PolygonScan. 725 total transactions. First activity approximately 4 years 145 days before assessment date (consistent with January 2022 mainnet deploy). Normal protocol development history; no linked-to-prior-rug pattern identified.
RD-F-115 green Prior rug/exit-scam affiliation No evidence of any Axelar team member linked to a prior rug or exit-scam. Multiple explicit searches yield zero adverse results. Axelar's own anti-scam blog post confirms third-party impersonation scams exist but these are not team-originated. No team member social handle, address, or identity appears in rug-pull databases.
RD-F-116 green Contributor tenure at admin-permissioned PR Recent axelar-core commits (Feb-Mar 2026, versions v1.3.10 and v1.4.0) show contributors jakovmitrovski, cgorenflo, themicp, h4writer, chipshort — all appear to be long-standing contributors based on commit history back to protocol inception. No newly-onboarded contributor with minimal tenure identified for recent admin-permissioned changes. Confidence medium — full contributor tenure history not individually verified.
RD-F-118 green Handle reuse across failed/rugged projects No handle reuse identified across failed or rugged projects. X/Twitter handle @axelar consistent with full 4-year history since 2021 inception. Sergey Gorbunov's handle @sergey_nog referenced in official Axelar tweets — consistent with known identity. No alias changes or cross-project handle reuse found. Scam accounts are impersonation-only.
RD-F-120 green Video-off/voice-consistency flag Sergey Gorbunov and Georgios Vlachos have participated in numerous public video and podcast appearances over 4+ years. Gorbunov appeared in YouTube interviews, HackerNoon, and at an in-person SEC meeting (Jun 2025). Vlachos presented in person at Southeast Asia Blockchain Week 2024 (Singapore) and Cosmoverse (Medellin, Colombia), and appeared on CryptoNews podcast ep 387 (Nov 2024). No video-off or voice-consistency concerns flagged. Both have been seen and heard in person at named events.
RD-F-121 green Contributor OSINT depth score Gorbunov: 5/5 — PhD MIT (Sprowls Prize), Microsoft PhD Fellow, UWaterloo Assistant Professor, peer-reviewed publications at top-tier venues, EU FENTEC technical advisor, SEC meeting participant, extensive YouTube/podcast presence. Vlachos: 5/5 — MIT MS/BS, IMO Gold Medal 2011 (first Greek student), Algorand Head of Math, in-person conference appearances across multiple continents, podcast appearances, LinkedIn full history. Overall team OSINT depth is exceptionally high.
RD-F-122 green Contributor paid to DPRK-cluster wallet No evidence of any Axelar contributor payroll routing to DPRK-labeled wallets. Multiple searches for 'Axelar Network contributor payroll DPRK North Korea Lazarus supply chain 2024 2025' return zero Axelar-specific adverse results. General DPRK supply-chain threat (npm packages, etc.) is an industry-wide concern not specific to Axelar. Individual contributor payment wallet traces not completed — requires on-chain tooling. Adverse-evidence search is clean.
RD-F-124 green Deployer wallet mixer-funded within 30 days Deployer 0xa57adce1d2fe72949e4308867d894cd7e7de0ef2 was funded approximately 4 years 145 days ago by 0xE7bc267a6c1ebe7d4a72341c1bf277f8ae478540, which itself was funded from AscendEX Hot Wallet (Etherscan label confirmed). AscendEX is a centralized exchange — not a privacy mixer. No Tornado Cash, Railgun, or equivalent mixer interactions identified within 30 days of the mainnet deploy (approximately January 2022). The 30-day pre-deploy window is clean. The intermediate wallet (0xE7bc267a) has 99 total transactions and last active July 2023 — consistent with a relay/operational wallet, not a laundering vehicle.
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No OFAC SDN-listed address in the deployer funding chain (AscendEX Hot Wallet at 2-hop). No Chainalysis-labeled or publicly-documented Lazarus cluster address identified in any search. Multiple explicit searches ('Axelar Network Interop Labs Sergey Gorbunov DPRK OR Lazarus OR North Korea') return zero adverse results. Axelar bridge used as a passive cross-chain venue by potentially-DPRK-linked funds does NOT constitute team-level cluster proximity per rubric — that is a Cat 11 (realtime-intel) finding. No F125 red trigger applicable. DPRK-confirmed escalation: NOT required.
Fork / dependency lineage Green 0 10 of 10
RD-F-126 n/a Is-a-fork-of Axelar is an original protocol. axelar-core (Go/Cosmos-SDK) and axelar-cgp-solidity (EVM) are original Axelar designs, not forks of any specific DeFi protocol. Profile §5 explicitly states: Not forked / original. Bytecode similarity to known upstream DeFi protocols not applicable. RD-F-127 n/a Upstream patch not merged Not applicable: Axelar has no upstream fork protocol to propagate patches from. Original protocol. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) Not applicable: Axelar has no upstream fork protocol whose vulnerability disclosures would propagate. Original protocol. RD-F-129 n/a Code divergence from upstream (%) Not applicable: No upstream fork baseline exists to measure code divergence against. Axelar is an original protocol. RD-F-130 n/a Fork depth (generations from original audit) Not applicable: Fork depth is 0 by construction (original protocol). No fork chain exists. RD-F-131 n/a Fork retains upstream audit coverage Not applicable: No upstream protocol audit exists to inherit or diverge from. Axelar has its own independent audit trail. RD-F-132 n/a Fork has different economic parameters than upstream Not applicable: No upstream protocol with audited economic parameters to compare against. Axelar's gateway parameters are original.
RD-F-133 green Dependency manifest uses unpinned versions axelar-cgp-solidity package.json: sole production dependency is @axelar-network/axelar-gmp-sdk-solidity pinned exactly at version 6.0.6 (no caret or tilde). No OpenZeppelin production dependency exists (Axelar uses its own gmp-sdk). axelar-core go.mod pins Cosmos SDK to a specific Axelar fork commit (v0.50.14-0.20251027135325-71cefd84b6c7). Critical library pinning is exact.
RD-F-134 green Dependency had malicious-release incident (last 90d) No malicious-release advisory found for @axelar-network/axelar-gmp-sdk-solidity@6.0.6 or confirmed Axelar Go dependencies in the trailing 90 days. No GHSA or npm advisory flagged. Standard security monitoring applies.
RD-F-135 green Shared-library version with known-vuln status The primary EVM shared library is @axelar-network/axelar-gmp-sdk-solidity v6.0.6 (Axelar's own library - no OZ/Solady production dependency in axelar-cgp-solidity). The Go Cosmos SDK dependency is pinned to an Axelar fork (0.50.14) with no confirmed high/critical GHSA advisory found. No CVE for the pinned Cosmos SDK version identified.
Post-deploy hygiene & change mgmt Green 19 13 of 13
RD-F-136 yellow Deployed bytecode matches signed release tag axelar-cgp-solidity has tagged releases (v6.4.0 as Oct 2024 latest in the primary repo). No explicit bytecode-to-release-tag verification table found. Foundry not used (data cache: foundry_toml_present=false); Hardhat used. Reproducible build verification not confirmed publicly. Some releases may match deployed bytecode but the mapping is not published. RD-F-137 yellow Upgrade frequency (per 90 days) InterchainTokenService proxy: 6 total upgrades between March 2024 and July 2025 (~1 every 2.5 months). AxelarGateway proxy: no upgrades detected in last 90 days (stable). ITS upgrade frequency is moderate-to-high for a bridge protocol. The gateway core is stable; ITS is actively evolving. RD-F-138 yellow Hot-patch deploys without timelock (last 30 days) ITS upgrades confirmed as direct bare-EOA calls (0x6f24A47Fc8AE5441Eb47EFfC3665e70e69Ac3F05) with NO timelock. Jul 2025 upgrade tx 0x59a8471b... and Feb 2025 upgrade tx 0x630d798e... both show FROM=0x6f24... (bare EOA) directly calling upgrade() on ITS proxy. No timelock or multisig intermediary confirmed on-chain for any ITS upgrade. The prior 'Unknown [?]' is now resolved to 'NO timelock' for all 6 ITS upgrades. RD-F-139 yellow Post-audit code changes without re-audit ITS proxy underwent 6 upgrades (Mar 2024 – Jul 2025). Axelar's audits repo shows ITS coverage: Ackee Jan 2025, NCC at multiple dates (Mar/Jun/Nov 2024, Jan/Apr 2025), Arda Apr 2025. The Jul 2025 upgrade is within ~3 months of most recent confirmed audits (Apr 2025). However, no explicit audit commit-SHA-to-upgrade mapping is published. Some delta changes between audits and upgrade deployments may be un-audited. 70+ total audits suggest strong overall coverage discipline. All upgrades executed directly by EOA with no timelock, which increases urgency of audit coverage. RD-F-142 yellow Storage-layout collision risk across upgrades AxelarGateway uses EternalStorage pattern (key-value mapping) which is structurally collision-resistant across upgrades. ITS uses EIP-1967 proxy with standard upgradeable storage layout — 6 upgrades without reported storage collision. OZ upgrades plugin usage not confirmed. Manual storage layout review not performed in this session. RD-F-143 yellow Reinitializable implementation (no _disableInitializers) AxelarGateway implementation (0x99B5FA03...) does NOT call _disableInitializers() in constructor. Uses setup() with onlyProxy modifier instead — setup() reverts if called directly on the implementation (not via proxy). This is a non-OZ pattern providing a different mitigation: direct setup() calls on implementation revert via onlyProxy. ITS Upgradable base (axelar-gmp-sdk-solidity/Upgradable.sol) also confirmed to have no _disableInitializers(). Attack vector requires bypassing onlyProxy, which is harder than the unguarded OZ initialize() class. RD-F-145 yellow Deployed bytecode reproducibility Hardhat-based build (not Foundry). Data cache shows changelog_present=false and security_md_present=false. No public build-artifact reproducibility documentation found. Release tags exist in axelar-cgp-solidity but a full bytecode-reproducibility guide is not confirmed published. RD-F-168 gray Stale-approval exposure on deprecated router No deprecated routers explicitly identified in current Axelar EVM architecture with confirmed material TVL. An allowance scan across ITS v1/v2 migration was not performed in this session. Gap for curator follow-up on any user approvals to older ITS versions.
RD-F-140 green Fix-merged-but-not-deployed gap Code4rena 2023-07 H-01 and H-02 were both marked fixed via specific PRs (PR#102 and PR#96 respectively). No known outstanding un-deployed vulnerability fixes identified. Axelar's active audit engagement (70+ reports) reduces the likelihood of long-standing undeployed fixes.
RD-F-141 green Test-mode parameters in deploy No test-mode parameters identified in production contracts. InterchainGovernance constructor args match declared mainnet architecture. Admin is not the gateway deployer EOA (see RD-F-043). No infinite allowance or test oracle patterns observed. Protocol has been live for 4+ years with mature operational posture.
RD-F-144 green CREATE2 factory permits same-address redeploy No CREATE2 factory with same-address redeployment pattern identified in Axelar's EVM contract architecture. TokenDeployer is protocol-controlled. No evidence of CREATE2 redeploy-to-same-address risk in audits or source inspection.
RD-F-146 green New contract deploys in last 30 days ITS proxy last upgraded July 9, 2025 (approximately 311 days before assessment date of May 2026). No major gateway or ITS upgrades in the last 30 days (since approximately April 17, 2026) based on available Etherscan data. No significant new attack surface deployed in trailing 30 days.
RD-F-185 green Bridge rate-limiter / chain-pause as positive mitigant Confirmed positive mitigant. (1) Gateway setTokenMintLimits() implements per-token per-6h transfer rate caps (mintLimits) set by the Multisig mintLimiter — documented in Axelar security docs: 'gateways have a rate limiting function, putting a cap on how much of each asset can be transferred in a given time interval.' (2) Cosmos chain has governance-triggered emergency capability: governance proposal 256 disabled the auto-deregistration mechanism that was the attack vector in the 2024 vulnerability disclosure, demonstrating chain-level governance rapid response. (3) Validator quorum can disconnect compromised chains via governance vote. NOTE: ITS setPauseStatus() by single EOA is a negative factor (F027/F041), not counted here. The gateway-level controls are the positive mitigants for this factor.
Cross-chain & bridge Green 18 12 of 12
RD-F-148 yellow Bridge validator count (M) ~47 active validators on mainnet per staking-explorer.com data. For cross-chain signing, the active validator subset (Chain Maintainers) must meet the 60% weighted quorum. Quadratic voting (weight = sqrt(stake)) dampens concentration — top validator (Cosmostation) has ~4.8% of stake but less than 4.8% of signing weight due to quadratic dampening. Yellow because 47 validators is above an absolute minimum but the 60% signing quorum means a coordinated 41% weighted-voting-power attack could halt operations. RD-F-149 yellow Bridge validator threshold (k-of-M) 60% weighted quorum for cross-chain operation enabling (minimum quorum 0.6 from total consensus weight); 2/3 (~67%) for block finality on the Cosmos chain. Quadratic weighting (sqrt(stake)) moderates concentration. The EVM-side AxelarAuthWeighted uses a weighted threshold where weight >= threshold triggers approval. Threshold is governance-configurable. Yellow because 60% threshold means a coordinated attack by validators controlling >40% of weighted voting power could block or compromise operations — meaningful but non-trivial attack complexity for a live PoS network. RD-F-150 yellow Bridge validator co-hosting Top validators are institutional staking services (Cosmostation, Everstake, Figment, Imperator.co, Citadel.one) likely operating independent infrastructure. Top 5 control ~21% of visible stake; quadratic weighting further reduces individual impact. No OSINT evidence of single-datacenter co-hosting confirmed, but institutional validators commonly use major cloud providers (AWS, GCP, Hetzner), introducing some co-hosting probability. ASN-level verification not possible via available sources. RD-F-155 yellow Bridge validator-set rotation recency Axelar validator set requires periodic key rotation per protocol design. The 2024 vulnerability disclosure (chain-halt via auto-deregistration) was patched via governance proposal 256. No confirmed validator-set freeze or stale key issue identified. However, the exact date of the most recent OperatorshipTransferred event on AxelarAuthWeighted was not extracted in this session — requires axelarscan.io event log or Etherscan event filter. Yellow pending curator confirmation of last rotation date. RD-F-156 yellow Bridge uses same key custody for >30% validators Top 5 validators (Cosmostation, Everstake, Figment, Imperator.co, Citadel.one) control ~21% of visible stake. No single entity confirmed above 30% stake. Quadratic weighting reduces individual concentration impact further. However, institutional validators commonly use major cloud providers, introducing potential co-custodian risk. No OSINT evidence of a single custodian holding >30% of validator keys, but ASN/custody verification is not possible via available sources. RD-F-157 yellow Bridge TVL per validator ratio $144.73M TVL / ~47 active validators = ~$3.08M TVL per validator. This is a moderate ratio for a mature PoS bridge. The quadratic weighting means compromise of the largest validator (Cosmostation, ~4.8% stake) would have sub-linear impact on signing weight. Yellow because the ratio is not catastrophically high, but $3M+ per validator represents meaningful economic incentive for targeted validator compromise. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) NOT APPLICABLE — Axelar is its own cross-chain messaging infrastructure. It is not a LayerZero OApp and does not use DVN (Decentralized Verifier Network) configuration. F179 applies only to LayerZero OFT integrations. Data cache confirms layerzero.present: false and layerzero_bridge: false. Profile §11 explicitly states F179 is N/A.
RD-F-147 green Protocol has bridge surface YES — Axelar IS a cross-chain bridge. AxelarGateway deployed on ~60 EVM chains; Cosmos L1 (axelar-dojo-1) routes and verifies messages; InterchainTokenService (0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C) enables canonical token bridging. TVL $144.73M. has_bridge_surface: true, is_a_bridge: true per profile.
RD-F-151 green Bridge ecrecover checks result ≠ address(0) [★ CRITICAL] Source-verified GREEN. Axelar's custom ECDSA.sol library implements explicit zero-address revert: if ((signer = ecrecover(hash, v, r, s)) == address(0)) revert InvalidSignature(). The _validateSignatures() function in AxelarAuthWeighted.sol calls ECDSA.recover() which provides this guard. Malformed signatures that recover to address(0) are explicitly rejected before comparison with operators. Wormhole-class ecrecover zero-address attack vector is structurally mitigated.
RD-F-152 green Bridge binds message to srcChainId AxelarGateway.execute() includes explicit chain ID binding: if (chainId != block.chainid) revert InvalidChainId(). Commands are rejected if sent to the wrong destination chain. Source-verified.
RD-F-153 green Bridge tracks nonce-consumed mapping AxelarGateway uses commandId tracking for replay protection: if (isCommandExecuted(commandId)) continue; and _setCommandExecuted(commandId, true) before execution. Each unique commandId can execute exactly once. Replay protection is structural and verified in source.
RD-F-154 green Default bytes32(0) acceptable as valid root [★ CRITICAL] Source-verified GREEN. In AxelarAuthWeighted.validateProof(): if (operatorsEpoch == 0 || epoch - operatorsEpoch >= OLD_KEY_RETENTION) revert InvalidOperators(). A bytes32(0) operatorsHash would produce epochForHash[bytes32(0)] == 0 (default mapping value) triggering this revert. Additionally, _transferOperatorship() prevents zero-operator sets (operatorsLength == 0 reverts with InvalidOperators) and prevents duplicate hashes. Nomad-class default-value root acceptance is structurally blocked.
Threat intelligence & recon Green 17 8 of 8
RD-F-161 yellow Protocol-impersonator domain registered (typosquat) Applicable with elevated risk: Axelar has multiple high-value brand surfaces — axelar.network, axelarscan.io, satellite.axelar.network (redirects to squidrouter.com), squidrouter.com. Typosquat candidates: axe1ar.network, axelar.io, axelarscan.com, squidrouter.io, satellite-axelar.network. No confirmed typosquat domain identified via public web search as of 2026-05-17. However, no dedicated WHOIS/domain-monitoring feed was run for this assessment (gap). Yellow assigned because: (1) high-value brand with $144M TVS creates persistent typosquat incentive; (2) satellite.axelar.network brand migration to squidrouter.com creates ambiguity that opportunistic squatters exploit; (3) no active monitoring confirmed; (4) no confirmed typosquat found but monitoring gap exists. RD-F-163 yellow Avg attacker reconnaissance time for peer-class protocols Analytical field: for bridge protocols in the $100M–$500M TVL class, documented attacker reconnaissance periods range from days (Ronin — social engineering fast, exploit same day) to 6 months (Drift/UNC4736 — conference attendance, real capital deposits, durable-nonce pre-signing). USPD model: 78-day average. Axelar at $144M sits in the primary target band. No active reconnaissance wallets identified via public sources. Yellow: protocol is in the target class for Lazarus-style bridge attacks; structural recon risk is non-trivial given TVL level and bridge architecture (validator key management is the primary attack surface). RD-F-158 gray Known-threat-actor cluster has touched protocol T-09 phase-2 signal. Applicable: Axelar ($144M TVL bridge) is in the Lazarus/DPRK target class — bridges have been the primary vector (Ronin $625M 2022, Harmony Horizon $100M 2022, Drift $285M Apr 2026). Threshold: wallet in curator threat-actor cluster interacts with Axelar core contracts within last 30 days. No licensed TI feed (Chainalysis/TRM) wired. Public-proxy observation: no confirmed Lazarus/DPRK wallet interaction with Axelar contracts published as of 2026-05-17. Requires licensed attribution feed for definitive assessment. RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) Applicable: probing Axelar EVM gateway with low-gas failing transactions is a reconnaissance signal. V2-deferred signal; requires mempool listener + threat-actor cluster list. No public mempool probe report against Axelar identified. The 2024 chain-halt vulnerability (proposal 256) was disclosed via Immunefi as a legitimate whitehat bounty — no attacker probe pattern associated. RD-F-164 gray Leaked credential on paste/sentry site Manual OSINT only. No active credential leak referencing Axelar infrastructure endpoints or keys found via public web search as of 2026-05-17. Axelar runs distributed validator and relayer infrastructure (vald software, relayer keys); multiple credential surfaces exist. Curator must run targeted paste-site / GitHub secret-scan / Sentry-alt search for axelar.network endpoint references. No public advisory about Axelar credential leaks found. RD-F-165 gray Protocol social channel has scam-coordinator flag Curator social watchlist required. Axelar has Discord and community channels. Discord URL not enumerated in the protocol profile (profiler gap). Cannot assess without Discord URL and curator scam-coordinator watchlist cross-reference. No Discord-based scam incident confirmed via public search as of 2026-05-17. Gap flagged for curator to enumerate Discord URL from axelar.network and run watchlist check.
RD-F-160 green GitHub malicious-dependency incident touching protocol deps No GitHub Security Advisory flagging a malicious dependency in axelar-core (Go) or axelar-cgp-solidity (Solidity) dependencies identified as of 2026-05-17. axelar-core v1.3.10 is the current release (2026-02-17). Axelar has an active audit program with 60+ reports covering dependency surfaces. No active CVE or GHSA targeting Axelar's dependency tree found in public advisory feeds.
RD-F-162 green Known-exploit-template selector deployed by any address No known-exploit-template selector-pattern (targeting Axelar's ecrecover-weighted-multisig or GMP routing patterns) deployed by any address identified via public sources. The primary Axelar-class exploit template would target the AxelarAuthWeighted weighted-multisig ecrecover pattern or the InterchainGovernance relay; no public report of such a template deployment identified as of 2026-05-17. V2-deferred signal.
Tooling / compiler / AI Green 17 5 of 5
RD-F-170 yellow Solc version used (known-bug versions flagged) AxelarGateway.sol (deployed Ethereum mainnet impl 0x99B5FA03) was compiled at Solidity 0.8.9+commit.e5eed63a. hardhat.config.js configures 0.8.9 as primary compiler and 0.8.23 for AxelarGasService. Solidity 0.8.9 has one documented known bug: UserDefinedValueTypesBug (storage layout for user-defined value types shorter than 32 bytes, severity: very low). No high/critical bugs documented specifically for 0.8.9. Version is 3+ years old and outdated relative to current practice (0.8.25+). Yellow: on an outdated version but no high/critical bugs specifically affecting 0.8.9. RD-F-174 yellow Dependency tree uses EOL Solidity version AxelarGateway.sol (primary Ethereum mainnet gateway) compiled at Solidity 0.8.9 (released 2021-09-29, over 3.5 years old). While Solidity has no official EOL schedule, 0.8.9 is 16+ minor versions behind current 0.8.25+ practice and predates numerous compiler improvements. GasService uses 0.8.23 (more current). InterchainGovernance uses 0.8.19. The primary gateway implementation uses an outdated compiler version for a high-TVL contract. Yellow: core contract on outdated but not critically buggy compiler version. RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation Not applicable: Axelar is an original protocol with no audited upstream codebase to compare bytecode against for behavioral deviation. The factor measures AI-generated copy risk via similarity to an audited upstream, which does not apply to original designs.
RD-F-172 green Repo shows AI-tool co-authorship in critical files No GitHub commit metadata showing AI-tool co-authorship (Copilot, ChatGPT Code Interpreter co-authored-by trailers) found in public commit history for axelar-cgp-solidity or axelar-core repositories. No AI-disclosure found via web search. Standard commit attribution patterns observed.
RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure (blog, tweet, docs) from Axelar/Interop Labs indicating AI-generated Solidity was used in security-critical paths found. Web search returned no such disclosure.
Response & disclosure hygiene Green 8 4 of 4
RD-F-176 yellow Disclosure SLA public Partial SLA only. GitHub security policy states a 48-hour confirmation window (first-response SLA). No full resolution SLA or maximum hold period published. Immunefi program specifies Category 3 (researcher must obtain Axelar approval before publication) without bounding the timeline. The 2024 responsible disclosure took ~5 months from initial report to governance resolution — slow but coordinated and appropriate given the governance-required fix. No end-to-end disclosure timeline publicly committed.
RD-F-175 green Disclosure channel exists Multiple active disclosure channels confirmed: (1) Immunefi program at immunefi.com/bug-bounty/axelarnetwork/ live since 2022-03-11, updated 2026-03-09, max $500k payout; (2) security@interoplabs.io per GitHub security policy; (3) axelar-security@commonprefix.com per Axelar docs. Three independent disclosure paths; unambiguously green.
RD-F-177 green Prior known-ignored disclosure No evidence of any disclosed vulnerability that Axelar ignored prior to exploit. The 2024 vulnerability disclosure was acted upon promptly by the team (classified Critical, resolved via governance proposal 256, $50k bounty paid). No exploit post-mortem exists citing a prior unheeded disclosure (no exploits occurred). Hacksdatabase and REKT News confirm zero incidents.
RD-F-178 green CVE/GHSA advisory issued against protocol No CVE, GHSA, or equivalent public advisory issued against Axelar's protocol. GitHub security page for axelar-core shows no published security advisories. The 2024 responsible disclosure was handled via Immunefi private submission and governance — not converted to a public CVE or GHSA. Corroborated by web search finding no CVE for Axelar.
rubric_version v1.7.0 graded_at 2026-05-16 21:57:51 factors 184 protocol axelar