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

Decentralized Validation

Users submit program transaction requests through an RPC interface, providing the associated Bitcoin state anchors, input data, and transaction fees (paid in BTC). Each node of the Decentralized Verifier Network distributes the request within the network, runs the program request, signs off on the result, and shares the signed result with the elected leader node. As soon as a threshold of signatures has been collected, the leader node submits the resulting Bitcoin transaction.

The Decentralized Verifier Network is designed to be permissionless, maintaining the trustless environment characteristic of Bitcoin and allowing for anyone to participate in the ecosystem’s security and verification processes. It uses a gossip protocol to efficiently propagate information across the network, ensuring that all verifiers receive updates in a decentralized and fault-tolerant manner, helping maintain the network’s resilience and consistency.

PreviousBridgeless ExecutionNextState Transitions Anchored on Bitcoin

Last updated 7 months ago

🌟