Skip to content

LibraryInteroperability2021Design paperCorpus record

Axelar: cross-chain messages verified by its validator set

Axelar. Axelar.

Axelar publishes cross-chain delivery verified by Axelar's own validator set, which runs a consensus the destination application is asked to trust.

A reading of the project's public design document. Not a copy, not a benchmark, and not an offer.

Axelar publishes cross-chain delivery verified by Axelar's own validator set, which runs a consensus the destination application is asked to trust.
Evidence
Primary paper
Re-measured
No
Assumptions
3
Records linked
6

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

  1. Claim 01 · Paper model

    The defect

    A proof of stake bridge is still a bridge. The question is whether the destination checks Axelar's consensus or a signature from an unnamed relayer.

  2. Claim 02 · Paper model

    The proposal

    Axelar publishes cross-chain delivery verified by Axelar's own validator set, which runs a consensus the destination application is asked to trust.

  3. Claim 03 · Paper model

    The mechanism

    The validator set attests a remote event. The application on the destination accepts that attestation.

  4. Claim 04 · Paper model

    The bound

    No validator count and no staked value is stated here.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

  1. 01 The defect

    Observation

    What the study says

    A proof of stake bridge is still a bridge. The question is whether the destination checks Axelar's consensus or a signature from an unnamed relayer.

    Model

    What has to hold

    You are reading Axelar's docs, not the IBC specification.

    Falsifier

    What would retire it

    Whose signatures does the destination gateway check?

  2. 02 The proposal

    Observation

    What the study says

    Axelar publishes cross-chain delivery verified by Axelar's own validator set, which runs a consensus the destination application is asked to trust.

    Model

    What has to hold

    You are reading Axelar's docs, not the IBC specification.

    Falsifier

    What would retire it

    Does the document claim a light client of the source chain, or a validator attestation?

  3. 03 The mechanism

    Observation

    What the study says

    The validator set attests a remote event. The application on the destination accepts that attestation.

    Model

    What has to hold

    No price, supply, yield, or adoption figure is added by this desk.

    Falsifier

    What would retire it

    Does the document claim a light client of the source chain, or a validator attestation?

  4. 04 The bound

    Observation

    What the study says

    No validator count and no staked value is stated here.

    Model

    What has to hold

    You are reading Axelar's docs, not the IBC specification.

    Falsifier

    What would retire it

    Does the document claim a light client of the source chain, or a validator attestation?

03 Sequence

One action, as an operating tape

  1. 01The validator set attests a remote event. The application on the destination accepts that attestation.
  2. 02Gateway contracts hold or mint assets. Their upgrade keys are a separate assumption from validator honesty.
  3. 03General message passing can carry an arbitrary payload. The payload's safety is the application's problem.

04 Load-bearing

The argument, and where a pitch drops it

  1. What the name has to mean

    The cut

    Axelar publishes cross-chain delivery verified by Axelar's own validator set, which runs a consensus the destination application is asked to trust.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    Honest-majority of Axelar is not honest-majority of the source chain.

  2. What actually moves

    The cut

    Gateway contracts hold or mint assets. Their upgrade keys are a separate assumption from validator honesty.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    No validator count and no staked value is stated here.

  3. What a later deployment may change

    The cut

    General message passing can carry an arbitrary payload. The payload's safety is the application's problem.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    A later client, parameter or reward formula is a different object from this paragraph.

05 Register

What has to be true

  • Model · Not re-measured

    You are reading Axelar's docs, not the IBC specification.

  • Model · Not re-measured

    The document is the one at the source URL. A marketing page with the same brand is not this text.

  • Model · Not re-measured

    No price, supply, yield, or adoption figure is added by this desk.

06 Divergence

What happened after the paper

This is not IBC. IBC verifies a light client. This design verifies Axelar consensus.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

  1. 0 of 3 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

The problem it names

A proof of stake bridge is still a bridge. The question is whether the destination checks Axelar's consensus or a signature from an unnamed relayer.

What the design proposes

  • The validator set attests a remote event. The application on the destination accepts that attestation.
  • Gateway contracts hold or mint assets. Their upgrade keys are a separate assumption from validator honesty.
  • General message passing can carry an arbitrary payload. The payload's safety is the application's problem.

How the mechanism is specified

  • The validator set attests a remote event. The application on the destination accepts that attestation.
  • Gateway contracts hold or mint assets. Their upgrade keys are a separate assumption from validator honesty.
  • General message passing can carry an arbitrary payload. The payload's safety is the application's problem.

What this page does not treat as proven

  • No validator count and no staked value is stated here.
  • Honest-majority of Axelar is not honest-majority of the source chain.
  • This is not IBC. IBC verifies a light client. This design verifies Axelar consensus.

Why the desk still reads it

Axelar publishes cross-chain delivery verified by Axelar's own validator set, which runs a consensus the destination application is asked to trust.

09 Lexicon

Terms, opened into the record

Gateway
The contract that accepts a remote attestation and releases or mints.
Validator attestation
A statement by Axelar's set. It is not a header proof of the source chain unless specified.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.