Arch Documentation
  • ♾️Introduction
  • 🌉History of Bitcoin Programmability
    • The Challenges Facing Bitcoin DeFi
  • Bitcoin-Native vs. Bitcoin L2s & Metaprotocols
    • Why L2s and Meta-protocols Aren’t Enough
  • 🔗Quick Links
  • FUNDAMENTALS
    • 🌟Introducing Arch
      • Arch’s Signature Scheme Model (FROST + ROAST)
      • How Arch Works
      • Bridgeless Execution
      • Decentralized Validation
      • State Transitions Anchored on Bitcoin
      • Minimized Trust Assumptions
    • Step-by-Step User Journey on Arch
      • How It Works
  • USE CASES
    • How Arch Unlocks the Core Pillars of DeFi
    • 💵Using multi-party programs to enable AMMs, LPs, and DEXs
      • 🤝Example: A Bitcoin DEX
      • 🪙StableCoin
  • DEVELOPERS
    • Overview
    • FAQ
  • The Future
    • 🗺️Roadmap
    • 🔎Audits
Powered by GitBook
On this page
  1. FUNDAMENTALS
  2. Introducing Arch

How Arch Works

PreviousArch’s Signature Scheme Model (FROST + ROAST)NextBridgeless Execution

Last updated 7 months ago

Arch’s FROST + ROAST signature scheme allows the Arch Validator Network to collectively generate Bitcoin addresses and sign Bitcoin transactions, while retaining the ability to dynamically add and remove nodes from the signers/validators set (this allows the network to be both decentralized and robust/fault-tolerant). Each node runs an instance of the program execution environment, maintains a database of the associated state, and provides an RPC interface for users to access the network.

🌟
OUTDATED DIAGRAM - NEW DIAGRAM COMING SOON