Verification

This page explains how AstralBeam verifies that every transfer is genuine before releasing tokens. It is a conceptual overview - no code required.

Two Directions, Two Verification Paths

EVM → Casper: Proof-Based Verification

When you lock tokens on an EVM chain, the bridge does not simply take a relayer's word that the deposit happened. Instead:

  1. Block headers are recorded on Casper - Once an EVM block is finalized, a majority of relayers jointly attest to it, and its fingerprint is stored on-chain on Casper. This is a signed header registry: the stored headers are trusted because a majority of independent relayers signed them - Casper does not itself verify EVM consensus.
  2. Each relayer proves your deposit - Every EVM block contains a cryptographic commitment (a Merkle root) to all of its transactions. Relayers independently produce and check a proof that your lock transaction is included in the recorded block.
  3. Casper re-checks the proof - The Casper contracts validate the proof against the stored block fingerprint before minting. A forged deposit would fail this check regardless of what any relayer claims.

The result: tokens cannot be minted on Casper without a genuine, finalized deposit on the EVM side.

Casper → EVM: Majority Attestation

Casper has fast deterministic finality, and the bridge uses a majority-attestation model in this direction:

  1. You burn (or lock) tokens on Casper.
  2. Before signing, each relayer independently re-fetches the transaction from the Casper network and verifies its execution effects against the chain itself - a relayer never co-signs a transfer it cannot confirm on-chain.
  3. A majority of relayer signatures is required before the EVM contract releases tokens.

The EVM contract verifies every signature on-chain and rejects anything short of the required majority.

Signatures

All approvals use industry-standard digital signatures (the same ECDSA scheme that secures Ethereum itself). The contracts recover each signer's identity from the signature and check it against the authorized relayer set - unknown or duplicate signers are rejected.

Replay Protection

Every approval is cryptographically bound to:

  • A specific chain - approvals include the chain identity, so a signature for one network is useless on any other
  • A specific transfer - each transfer carries a unique identity that the contracts mark as used; an approval can never be executed twice

Testing and Cross-Verification

The verification logic is implemented independently on both sides of the bridge and continuously tested against shared test vectors, ensuring both implementations agree on every hash and signature - byte for byte.

results matching ""

    No results matching ""