alpen-primary-sources-2026-05-02

Alpen primary-source snapshot

Fetched: 2026-05-02 UTC

1) Intro docs and repo README: what Alpen says it is

Source: https://docs.alpenlabs.io/ Source: https://docs.alpenlabs.io/welcome/readme.md?ask=Summarize%20Alpen%27s%20current%20architecture%2C%20EVM%20compatibility%2C%20Bitcoin%20data%20availability%2C%20and%20the%20current%20testnet%20limitations. Source: https://raw.githubusercontent.com/alpenlabs/alpen/main/README.md

Selected excerpts from the docs and repo README:

Alpen gives developers the freedom to program nearly any locking conditions for BTC imaginable, limited only by the Alpen block size and gas limits.

Technically speaking, Alpen is a work-in-progress EVM-compatible validity rollup on bitcoin.

Alpen is currently a work-in-progress EVM-compatible validity rollup on Bitcoin signet.

Additional signals from these materials:

• The docs and README are much more informative than the homepage and are the clearest first-party source of truth for this project
• Alpen is best understood as a Bitcoin-settled execution environment plus orchestration stack, not just a generic “Bitcoin L2” marketing label
• The current-network caveat matters: Alpen repeatedly documents that today’s network is still a signet-stage system rather than a finished mainnet rollup

2) Architecture and operating model

Source: https://docs.alpenlabs.io/how-alpen-works/system-architecture Source: https://docs.alpenlabs.io/how-alpen-works/strata-design-rationale

Selected excerpts from the official docs:

Alpen is an EVM blockchain that uses bitcoin as the source of truth for state commitments and proof of valid state transitions.

There are three layers: bitcoin layer at the base, Alpen layer above it, and the application layer that sits on top of the Alpen layer.

Alpen is actually two blockchains, with each full node able to run a client for each of the following layers: execution layer and orchestration layer.

In our architecture, the execution layer (Alpen) is an EVM environment implemented using a fork of Reth, while the orchestration layer (Strata) is a new blockchain tailored to orchestrate bridging operations, implement Alpen’s rollup design, and support the network’s consensus requirements.

Additional signals from the architecture materials:

• The execution-layer versus orchestration-layer split is a central design choice and a key reason Alpen should be cataloged as orchestration infrastructure, not only as an app chain
• The public docs also expose the role of the sequencer, prover, full node, bundler, and bridge operators with unusual clarity for a Bitcoin-rollup project
• Alpen explicitly extends the Engine API to accommodate bridge transfers and other Bitcoin-specific behavior, which is a helpful differentiator from generic EVM-rollup stacks

3) Compatibility and builder surface

Source: https://docs.alpenlabs.io/how-alpen-works/comparing-strata-and-ethereum Source: https://docs.alpenlabs.io/build-alpen-apps/deploying-alpen-smart-contracts

Selected excerpts from the official docs:

Alpen is an EVM-compatible blockchain.

Alpen is fully compatible with the EVM spec up to the Prague release, excluding type 3 transactions and blob-related upgrades (EIP-4844).

With these exclusions, Alpen can be considered a Type 2.5 zkEVM.

Before we deploy the contract, we need to make sure we can connect to the Alpen public RPC.

Additional signals from the compatibility and deployment docs:

• Alpen is not merely claiming abstract compatibility; it publishes concrete deployment walkthroughs, RPC endpoints, and node-operator docs
• The docs expose ERC-4337 bundling support and practical Solidity deployment flows, which makes the project easier to classify as live builder infrastructure rather than research-only architecture
• The chain currently uses BTC/sBTC as the gas asset on testnet, a meaningful operational difference from conventional Ethereum rollups

4) Bridge design and trust model

Source: https://docs.alpenlabs.io/how-alpen-works/bitcoin-bridge Source: https://docs.alpenlabs.io/how-alpen-works/system-architecture

Selected excerpts from the official docs:

The Strata bridge is run by a federation of operators who co-sign transactions to move BTC into and out of the bridge.

The bridge is based on BitVM2 which, unlike other multisignature-based bridges that need an honest majority to keep the funds safe, requires a single functional operator to guarantee the safety and liveness of the bridge.

Deposits and withdrawals are allowed in a fixed denomination of BTC. For the current testnet, this is set to 10 BTC. The withdrawal fee is set at 0.01 BTC.

Currently, all bridge operators are run by Alpen Labs. Incorporating external bridge operators is planned for a future Alpen release.

Additional signals from the bridge materials:

• The bridge docs are detailed enough to recover deposit and withdrawal flows, bond mechanics, challenge periods, and the current operational limitations
• Alpen should be categorized partly as BTC-bridge infrastructure because the bridge model is not a side note; it is structurally enshrined in the design
• The current centralization assumptions are clearly documented and should be retained in any downstream summary rather than glossed over

5) Testnet limitations and security posture

Source: https://docs.alpenlabs.io/welcome/readme.md?ask=Summarize%20Alpen%27s%20current%20architecture%2C%20EVM%20compatibility%2C%20Bitcoin%20data%20availability%2C%20and%20the%20current%20testnet%20limitations. Source: https://docs.alpenlabs.io/community/security

Selected excerpts from the official docs:

In testnet, Alpen is not using full onchain data availability yet. It runs on a private bitcoin signet and stores state commitments there instead of complete Alpen state data, so it behaves more like a commit chain right now.

The sequencer is centralized and run by Alpen Labs.

All bridge operators are run by Alpen Labs.

Current Security Status: The mainnet v1 contracts are currently under active audit. The reports listed below cover the Alpha/Testnet implementations.

Additional signals from the security materials:

• Alpen documents its current trust assumptions unusually directly, which improves the usefulness of the project file for future comparison work
• The public security page is a meaningful primary source because it links third-party audits, Immunefi, and responsible-disclosure contacts
• This pass did not surface a canonical Alpen whitepaper or litepaper; docs and code remain the primary source of truth

Notes

• Alpen appears best cataloged as Bitcoin validity rollup / EVM-compatible execution layer / BitVM2 bridge and orchestration infrastructure.
• The docs corpus is the canonical source of truth in this pass; the public site is comparatively thin.
• No Alpen-specific whitepaper or litepaper was found during this pass.