Security Model
AstralBeam is designed so that no single party - including the bridge operators - can move your funds alone. This page explains, at a high level, how the bridge keeps transfers safe.
The Three Pillars
Independent cryptographic verification - Every transfer must be proven, not just claimed. Before approving a transfer from an EVM chain, each relayer independently verifies a cryptographic proof that your deposit really happened in a finalized block.
Majority approval (multi-signature) - The bridge is operated by a network of independent relayers. A majority of them must approve every transfer. Compromising a single relayer - or even two - is not enough to move funds.
On-chain validation - Approvals are checked again by the smart contracts themselves before any tokens are released. A false approval fails on-chain, even if a relayer misbehaves.
flowchart LR
Transfer[Your transfer] --> Proof[Cryptographic proof verified by each relayer]
Proof --> Majority[Majority of relayers approve]
Majority --> OnChain[Smart contract re-validates on-chain]
OnChain --> Release[Tokens released]
Finality Protection
Blockchains can occasionally reorganize their most recent blocks. To make sure a deposit can never be reversed after the bridge acts on it, transfers only proceed once the source chain has finalized the transaction - the point where the chain guarantees it is irreversible. The bridge additionally enforces its own minimum confirmation depth per chain, and fails safe (waits) if finality information is unavailable.
This is why an EVM → Casper transfer takes several minutes: the bridge is deliberately waiting for the source chain to make your deposit permanent.
Replay Protection
Every approval is bound to a specific transfer on a specific chain:
- Chain-bound - An approval for a transfer on one chain can never be reused on another.
- One-time use - Each transfer is tracked on-chain and can only be executed once. Re-submitting an old approval does nothing.
Transfer Limits
The bridge enforces minimum transfer amounts to prevent spam and dust attacks. Transfers below the minimum are rejected before any funds move.
Threat Model
| Threat | Mitigation |
|---|---|
| A relayer is compromised | A majority of relayers must approve every transfer; one bad actor cannot move funds |
| Source chain reorganization | Transfers wait for chain finality before processing |
| Faked deposit event | Deposits must be cryptographically proven against the finalized chain state |
| Replaying an old transfer | Every transfer is single-use and chain-bound |
| Tampering with relayer communication | All relayer-to-relayer traffic is encrypted and authenticated |
Trust Assumptions
Like every cross-chain bridge, AstralBeam's security rests on a small set of assumptions:
- Honest majority of relayers - a majority of the independent relayer operators behave honestly
- Source and destination chains are secure - the connected blockchains themselves operate correctly
- Sound cryptography - the industry-standard cryptographic primitives used remain secure
Emergency Controls
Bridge contracts can be paused in an emergency, immediately halting new transfers while the situation is investigated. Funds already at rest are unaffected by a pause. Administrative actions are themselves protected by multi-signature approval.
Best Practices for Users
- Always access the bridge at astralbeam.io - bookmark it, and beware of lookalike sites
- Verify token and network selections before confirming a transfer
- Start with a small test transfer when bridging a token for the first time
- Never share your seed phrase or private keys - the bridge will never ask for them
Learn More
- Verification - a deeper look at how transfers are verified
- Audits - independent security reviews of the bridge