Introduction to Alpen

Last updated 5 hours ago

Introduction to Alpen

Alpen gives developers the freedom to program nearly any locking conditions for BTC imaginable, limited only by the Alpen block size and gas limits. This enables developers to create new kinds of applications for BTC with features such as:

New signature types, "provide a valid P-256 signature to authorize a transfer"
Vaults, "transfers must wait N days after being initiated to be effectuated, and can be cancelled in the mean time"
Subscriptions, "address 0x123...9a can withdraw up to v BTC per month from this account"
Strong privacy, "transaction details are end-to-end encrypted and verified using a zero-knowledge proof"
Economically secured zero-confirmation payments, "if a double-spend from this sender is reported, the reporter gets to claim the sender's full wallet balance"
Financial transactions, "if enough BTC is locked as collateral to maintain up to X% loan-to-value ratio, then up to Y of this other asset can be borrowed"

... and many more possibilities.

Technically speaking, Alpen is a work-in-progress EVM-compatible validity rollup on bitcoin. Let's break down what this means:

EVM-compatible: The Alpen sequencer runs a client that is based on , an Ethereum execution client. So far, no changes have been made that affect with the EVM spec. If you can deploy a smart contract to Ethereum, you can deploy it to Alpen with no changes.
Validity rollup: Every Alpen state transition is proven to be valid using cryptographic validity proofs, which clients can use for fast, low-cost verification.
On bitcoin: Alpen uses bitcoin for consensus and data availability. When an Alpen block gets confirmed on bitcoin, the only way to reorganize this block is to reorganize the bitcoin block that the Alpen block was confirmed in.

You can find detailed technical information in the section of this documentation.

During the testnet phase, Alpen will be running on a private bitcoin signet, and will use signet blocks to store state commitments rather than the complete Alpen state data, making Alpen function more like a commit chain than a rollup. Support for full onchain data availability and for running Alpen on bitcoin mainnet are planned for future releases.

NextSystem architecture

Last updated 5 hours ago

New signature types, "provide a valid P-256 signature to authorize a transfer"
Vaults, "transfers must wait N days after being initiated to be effectuated, and can be cancelled in the mean time"
Subscriptions, "address 0x123...9a can withdraw up to v BTC per month from this account"
Strong privacy, "transaction details are end-to-end encrypted and verified using a zero-knowledge proof"
Economically secured zero-confirmation payments, "if a double-spend from this sender is reported, the reporter gets to claim the sender's full wallet balance"
Financial transactions, "if enough BTC is locked as collateral to maintain up to X% loan-to-value ratio, then up to Y of this other asset can be borrowed"

... and many more possibilities.

Technically speaking, Alpen is a work-in-progress EVM-compatible validity rollup on bitcoin. Let's break down what this means:

EVM-compatible: The Alpen sequencer runs a client that is based on , an Ethereum execution client. So far, no changes have been made that affect with the EVM spec. If you can deploy a smart contract to Ethereum, you can deploy it to Alpen with no changes.
Validity rollup: Every Alpen state transition is proven to be valid using cryptographic validity proofs, which clients can use for fast, low-cost verification.
On bitcoin: Alpen uses bitcoin for consensus and data availability. When an Alpen block gets confirmed on bitcoin, the only way to reorganize this block is to reorganize the bitcoin block that the Alpen block was confirmed in.

You can find detailed technical information in the section of this documentation.