1. Executive Summary

Stable Protocol introduces a new category of blockchain: the Attested Blockchain. All blockchains use Merkle proofs to verify what the state is—cryptographic proof that data is correct. Stable Protocol adds a second layer: TEE attestation proves how that state was computed—cryptographic proof of the execution environment, the code that ran, and the operator's identity.

The architecture works as follows: (1) validators reach consensus on transaction order using HotStuff BFT, (2) each validator executes transactions within its hardware-isolated TEE, (3) execution proofs combined with TEE attestations are generated, and (4) these attestation proofs are periodically anchored to Bitcoin, creating an immutable record that verified code running in verified environments produced the state.

1.1 A New Category: The Attested Blockchain

Blockchain infrastructure has evolved through distinct categories:

1.2 The Problem

Current blockchain infrastructure faces a fundamental tension between decentralization ideology and institutional requirements. While all blockchains provide cryptographic state verification through Merkle proofs, enterprises and governments require additional assurances: SOC 2 compliance, audit trails, defined SLAs, accountable infrastructure providers, and verifiable execution environments. Existing solutions cannot provide these institutional guarantees.

1.3 The Solution

Stable Protocol resolves this tension by building a purpose-designed Layer 1 blockchain that adds execution environment verification to standard cryptographic verification. Validators operate within hardware-isolated trusted execution environments (AWS Nitro Enclaves, Azure SEV-SNP, GCP Confidential Space) providing tamper-proof execution with cryptographic attestation. Attestation proofs are anchored to Bitcoin, creating an immutable audit trail of verified execution.

1.4 Key Differentiators

1. Layered Security Model: Standard Merkle proof verification PLUS TEE attestation of execution environment.
2. Cloud-Native Security: Validators run in hardware-isolated TEEs with cryptographic attestation across three major cloud providers.
3. MEV Mitigation: TEE hardware isolation prevents validators from extracting value through transaction reordering or front-running.
4. HotStuff Consensus: Pipelined BFT consensus achieving 1-2 second finality with linear O(n) message complexity.
5. Parallel EVM Execution: Block-STM style optimistic parallel transaction execution for 10,000+ TPS throughput.
6. Bitcoin-Anchored Attestation: TEE attestation proofs are periodically committed to Bitcoin, providing immutable evidence of verified execution.
7. Institutional Compliance: SOC 2, ISO 27001, and FedRAMP-ready infrastructure from day one.
8. Cross-Chain Interoperability: Bridge architecture enables asset movement between Stable Protocol and other chains.

1.5 Performance Advantages

TEE-enforced non-equivocation enables reduced validator requirements compared to traditional BFT:

2. Market Context

2.1 The Institutional Blockchain Gap

The blockchain industry has reached an inflection point. While retail adoption has driven the first wave of cryptocurrency growth, institutional capital remains largely on the sidelines due to infrastructure concerns. According to industry research, over $50 trillion in institutional assets await blockchain-native solutions that meet fiduciary standards.

Existing solutions fall into three categories, none of which adequately serve institutional needs:

• Public L1s (Ethereum, Solana, Avalanche): Cryptographically secure via Merkle proofs, but with anonymous operators, no SLA guarantees, and no execution environment attestation.
• Private/Permissioned Chains (Hyperledger, R3): Known operators but centralized with single points of failure and no public auditability.
• Bitcoin L2s (Lightning, Liquid, Stacks): Limited functionality, federated trust models, or optimistic verification.

2.2 The Accountability Problem

When an institution asks "who operates your validators and what code are they running?" the honest answer for most blockchains is "we don't know." While Merkle proofs cryptographically verify that the state is correct, they don't tell you who computed that state, what software they're running, or whether their execution environment has been compromised.

2.2.1 Merkle Proofs vs TEE Attestation

• Merkle Proofs (all blockchains): Cryptographically verify WHAT the state is. When a client queries any blockchain, it receives mathematical proof that the data is correct and part of the committed state. This is standard across all blockchains.
• TEE Attestation (Stable Protocol): Cryptographically verify HOW that state was computed. Proves the exact code that ran, that execution was isolated from tampering, and identifies the accountable operator. This is the additional layer Stable Protocol provides.

2.2.2 What TEE Attestation Adds

2.3 Target Markets

• Government and Public Sector: Digital identity, voting systems, public records, benefits distribution.
• Financial Services: Settlement systems, tokenized securities, cross-border payments, compliance automation.
• Healthcare: Medical records, supply chain verification, clinical trial data integrity.
• Enterprise: Supply chain management, audit trails, inter-company settlement, asset tokenization.

3. Technical Architecture

3.1 Architecture Overview

Stable Protocol is an independent Layer 1 blockchain with a four-layer architecture designed for institutional deployment. The protocol maintains its own ledger, consensus, and execution—while anchoring attestation proofs to Bitcoin for immutable timestamping.

3.1.1 Transaction Flow

The protocol operates in four phases:

1. Consensus: Validators use HotStuff BFT to agree on transaction order.
2. Execution: Each validator executes the ordered transactions within its hardware-isolated TEE.
3. Attestation: Execution proofs combined with TEE attestations are generated, proving verified code in verified environments produced the state.
4. Anchoring: Attestation proofs and state roots are periodically committed to Bitcoin.

3.1.2 Layer Structure

3.2 Multi-Cloud Validator Network

The foundation of Stable Protocol's security is hardware-isolated Trusted Execution Environments (TEEs) deployed across three major cloud providers: AWS Nitro Enclaves, Azure SEV-SNP, and GCP Confidential Space.

3.2.1 TEE vs HSM: Distinct Roles

3.2.2 Attestation Abstraction Layer

Cloud providers implement TEEs differently:

• AWS Nitro: Image SHA-384 measurement, vsock communication, minimal TCB
• Azure SEV-SNP: AMD measurement digests, MAA attestation service, full VM encryption
• GCP Confidential Space: AMD SEV measurement, Workload Identity Federation, zero-trust model

Stable Protocol implements an attestation abstraction layer that normalizes these formats into a unified verification structure for Bitcoin anchoring.

3.2.3 Trusted Execution Environment Properties

• Isolation: TEEs provide isolated execution environments with no persistent storage, no interactive access, and no external networking.
• Attestation: Cryptographic attestation documents prove validators are running expected code on genuine TEE hardware.
• Memory Encryption: All TEE memory is encrypted with keys inaccessible to cloud provider personnel or other processes.
• MEV Protection: Hardware isolation prevents validators from inspecting pending transactions or manipulating execution order for profit extraction.

3.3 HotStuff Consensus Mechanism

Stable Protocol employs HotStuff, a pipelined Byzantine Fault Tolerant (BFT) consensus mechanism co-authored by Dahlia Malkhi at VMware Research. HotStuff achieves 1-2 second finality with linear message complexity and powers production blockchains including Aptos and Flow.

• Linear Message Complexity: O(n) instead of O(n²), enabling better scalability.
• Pipelined Phases: Overlapping prepare/pre-commit/commit phases maximize throughput.
• Optimistic Responsiveness: Progress at network speed rather than worst-case timeouts.
• 3-Chain Commit Rule: Achieves finality in 3 rounds with mathematically proven safety.

3.4 TEE Security: Anti-Forking Protections

TEE-based systems face two categories of attacks: rollback attacks (restoring stale state) and cloning attacks (running duplicate enclaves). Stable Protocol mitigates these through:

• Monotonic Counters: Each TEE maintains a hardware-protected counter incremented with every state transition, preventing rollback.
• Consensus-Bound Attestation: Attestation documents include block height and state root, so duplicate enclaves produce detectable conflicts.
• State Serialization: Block height is verified within the enclave, preventing stale-state attacks.
• Unique Sequential Identifiers: Following the MinBFT paradigm, TEE-generated USIG certificates prove sequence numbers are uniquely bound to specific messages.

3.5 Parallel EVM Execution Layer

Stable Protocol implements Block-STM style optimistic parallel transaction execution within TEEs, enabling 10x-50x throughput improvement over sequential EVM execution.

Stable Protocol provides full Ethereum Virtual Machine compatibility. Developers deploy existing Solidity smart contracts without modification.

• Standard tooling: Hardhat, Foundry, Remix, Truffle
• Web3.js and ethers.js compatibility
• MetaMask and WalletConnect integration

3.6 Zero-Knowledge Privacy Layer

Stable Protocol employs zero-knowledge proofs for on-chain data to address critical regulatory requirements. By publishing only zero-knowledge proofs on-chain, the protocol ensures regulatory compliance while maintaining cryptographic verifiability.

3.7 Bitcoin Anchoring

Stable Protocol periodically commits attestation proofs and state root hashes to the Bitcoin blockchain, creating an immutable audit trail that verified execution environments produced the blockchain state.

Analogy: Bitcoin anchoring is like a company filing notarized documents. The notary does not run the company or validate its operations—it provides independent, tamper-proof evidence that specific documents existed at a specific time.

3.7.2 What Bitcoin Anchoring Provides

• Immutable Attestation Record: Proof that specific TEE attestations existed at specific times, backed by Bitcoin's security.
• Audit Trail Integrity: Independent verification that historical states and attestations have not been retroactively altered.
• Regulatory Evidence: Court-admissible proof of historical records for compliance and dispute resolution.
• Fork Detection: Ability to detect if any party presents a fraudulent alternative history.

3.7.3 Anchoring Mechanism

• Frequency: Attestation proofs and state roots anchored every 100 blocks (~5-10 minutes).
• Method: OP_RETURN transactions containing attestation proof hash and Merkle root of protocol state.
• Verification: Anyone can independently verify that historical attestations and states match Bitcoin anchors.
• Cost: Minimal Bitcoin transaction fees (~$1-5 per anchor at typical fee rates).

3.8 Cross-Chain Bridge Architecture

Stable Protocol includes bridge infrastructure for asset interoperability with other blockchains:

• Ethereum Bridge: ERC-20 token transfers and smart contract interoperability.
• Bitcoin Bridge: BTC custody and wrapped Bitcoin on Stable Protocol.

Bridge security leverages TEE attestation—bridge operators run within the same verified execution environments as validators, with attestation proofs anchored to Bitcoin.

4. STP Native Token

Stable Protocol utilizes a native token called STP (Stable Protocol Token) for transaction gas fees. All operations on the network, including smart contract execution, token transfers, and state changes, require STP for gas payment.

The gas fee model ensures network sustainability while preventing spam and denial-of-service attacks. Gas fees are paid exclusively in STP, creating native demand proportional to network usage.

Detailed tokenomics, including total supply, distribution schedule, staking mechanisms, and governance rights, will be published in a separate Tokenomics White Paper prior to the token generation event.

5. Governance Framework

5.1 Programmatic Governance

Stable Protocol governance is enforced programmatically through the protocol itself. Code hash acceptance, upgrade procedures, and protocol parameters are defined in consensus rules and enforced automatically by TEE-attested validators.

5.2 Protocol Upgrades

Protocol upgrades require updating the accepted code hashes. To prevent network fragmentation:

1. New code hash is announced with a future activation block height.
2. During the transition window, both old and new code hashes are accepted.
3. Validators upgrade at their own pace within the window.
4. After transition, only the new code hash is valid.

6. Security Model

6.1 Defense in Depth

Stable Protocol employs a defense-in-depth security architecture with multiple independent security layers. Compromise of any single layer does not compromise the overall system.

6.1.1 Cryptographic Security (Merkle Proofs)

• Standard blockchain state verification via Merkle proofs
• Clients verify state cryptographically without trusting nodes
• Same verification model as Ethereum, Bitcoin, and other blockchains

6.1.2 Execution Security (TEEs)

• Hardware-level isolation of validator code
• Cryptographic attestation of running software anchored to Bitcoin
• Memory encryption inaccessible to host
• Anti-forking protections (monotonic counters, state serialization)

6.1.3 Key Security (Cloud HSM)

• FIPS 140-2 Level 3 certified key storage
• Keys never exist in plaintext outside HSM
• Full audit trail of all key operations

6.1.4 Consensus Security (BFT)

• TEE-enhanced 2f+1 fault tolerance threshold
• Economic security through staking and slashing
• Deterministic finality preventing reorganizations

6.1.5 Historical Security (Bitcoin)

• Immutable timestamp of attestation proofs and state roots
• Independent verification capability
• Leverages Bitcoin's 16-year security track record

6.2 Comparison to Alternative Security Models

6.3 Audit Program

Stable Protocol maintains a comprehensive security audit program including pre-launch audits by leading blockchain security firms, an ongoing bug bounty program, regular penetration testing, and continuous monitoring.

7. Team & Advisors

7.1 Core Team

Stable Protocol is led by a founding team with experience across blockchain technology, enterprise systems, and financial services. The team is committed to building institutional-grade infrastructure for the next generation of digital asset applications.

7.2 Advisory Board

Stable Protocol is assembling an advisory board with expertise in blockchain architecture, cloud infrastructure, regulatory compliance, and institutional finance. Advisory appointments will be announced as the project progresses.

8. References

• [1] Yin, M., Malkhi, D., Reiter, M.K., Gueta, G.G., Abraham, I. "HotStuff: BFT Consensus with Linearity and Responsiveness." arXiv:1803.05069, 2019.
• [2] Veronese, G.S., Correia, M., Bessani, A.N., Lung, L.C., Verissimo, P. "Efficient Byzantine Fault-Tolerance." IEEE Transactions on Computers, 2013.
• [3] Gelashvili, R., et al. "Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing." arXiv:2203.06871, 2022.
• [4] Karanjai, R., et al. "Lessons Learned from Blockchain Applications of Trusted Execution Environments." arXiv:2203.12724, 2022.
• [5] "The Forking Way: When TEEs Meet Consensus." arXiv:2412.00706, 2024.
• [6] Wong, D. "Beyond the Whitepaper: Where BFT Consensus Protocols Meet Reality." IACR ePrint 2024/1242.

9. Conclusion

Stable Protocol represents a new category of blockchain infrastructure: the Attested Blockchain—institutional-grade, verifiable, and compliant by design. By combining standard cryptographic verification (Merkle proofs) with Bitcoin-anchored TEE attestation, the protocol delivers:

• Cryptographic state verification (standard blockchain security)
• Bitcoin-anchored execution attestation (TEE verification of code and isolation)
• TEE-enhanced consensus (2f+1 threshold, 2 commit rounds)
• MEV protection through hardware isolation
• Operator accountability (known validators with audit trails)
• Institutional compliance (SOC 2, ISO 27001, FedRAMP-ready)
• Cross-chain interoperability via bridge architecture

The STP token powers all network operations through its utility as the native gas fee currency, ensuring sustainable network economics.

1. Introduction: A New Model of Decentralisation

The blockchain industry has long operated under a false dichotomy: either a network is decentralised through anonymous validators and token governance, or it is centralised under a single operator. Stable Protocol rejects this binary framing.

We have developed an architecture that achieves genuine decentralisation—not through anonymous actors or speculative token voting—but through the immutable properties of hardware isolation and cryptographic proof. We call this approach Verifiable Infrastructure.

This document explains how Stable Protocol achieves decentralisation through physics and mathematics rather than social coordination, and why this model provides stronger guarantees than traditional approaches while maintaining the accountability that institutional users require.

2. The Technical Foundation

2.1 Machine Validators in Trusted Execution Environments

Stable Protocol validators are not humans staking tokens. They are machine processes running in Trusted Execution Environments (TEEs) across three major cloud providers: AWS Nitro Enclaves, Azure SEV-SNP, and Google Cloud Confidential Space.

Each validator consists of two components:

• Parent Compute Instance: Handles networking, transaction mempool, smart contract execution via Geth EVM, storage, RPC requests, and logging.
• TEE Component: A cryptographically isolated environment that handles security-critical operations—private key storage, block signing, consensus vote signing, and attestation document generation.

The TEE provides hardware-level isolation with these properties:

• No persistent storage, no interactive access, no external networking—the enclave is completely isolated.
• Memory encryption—all TEE memory is encrypted with keys inaccessible to cloud provider personnel or other processes.
• Cryptographic attestation—proves the validator is running expected code on genuine TEE hardware.

2.2 Multi-Cloud Distribution

The validator set is distributed across three independent cloud providers:

3. The Structural Decentralisation Argument

3.1 What TEE Attestation Actually Means

When a validator runs in a TEE, the attestation process works as follows:

1. The code is measured—a cryptographic hash of the exact binary running in the enclave is computed by the hardware.
2. The hardware signs the measurement—the TEE hardware (not software, not the cloud provider) produces an attestation document.
3. Anyone can verify—the attestation cryptographically proves "this exact code is running on genuine TEE hardware."

The cloud providers do not "approve" code hashes in a governance sense. They provide the hardware that measures and attests. The attestation is a statement of fact: this code with this hash is running in a genuine enclave. This is enforced by silicon, not policy.

3.2 The Chain of Enforcement

The protocol's security model creates an unbreakable chain of enforcement:

• Consensus rules state: "Only accept blocks signed by validators whose attestation proves they are running Code Hash X."
• TEE hardware enforces: "I can only produce valid attestations for code that is actually running in my enclave."
• Multi-cloud architecture ensures: "No single cloud provider controls enough validators to dominate consensus."

3.3 The Self-Enforcing Protocol

This architecture creates a protocol that enforces itself:

• Existing validators enforce their own rules: The validators currently running have consensus rules embedded in their TEE-attested code. Those rules define what code hashes are valid, what state transitions are legal, and what blocks to accept.
• New code requires acceptance: If anyone deploys validators with different code, the new code has a different hash. Existing validators will not recognise that hash as valid. The new validators' blocks will be rejected. The network continues on the original rules.
• Modifications are visible: Any change to validator code results in a different attestation hash. This is cryptographically evident to anyone who verifies the attestation. Covert modification is technically impossible.

4. Understanding Control Versus Enforcement

4.1 What Stable Protocol Inc Controls

Stable Protocol Inc maintains operational control over:

• Cloud accounts—we pay AWS, Azure, and GCP for infrastructure.
• Instance lifecycle—we can start, stop, and redeploy validator instances.
• Code authorship—we write the validator software.
• Code deployment—we decide what code to deploy.

4.2 What Stable Protocol Inc Does Not Control

Despite operational control, Stable Protocol Inc does not control:

• Code execution: Once code is running in the TEE, the hardware enforces it. We cannot reach into a running TEE and modify its behaviour. No one can.
• Consensus rules: The rules are defined by the running code, not by corporate policy. We cannot override consensus without deploying new code—which changes the attestation.
• Attestation validity: The chip manufacturers (Intel, AMD, ARM) and their hardware determine attestation validity. We are tenants of this infrastructure, not controllers.
• State integrity: Cryptographic proofs and Bitcoin anchoring ensure state integrity independent of any operator.

4.3 The Control Hierarchy

5. Regulatory Compliance and Protocol Integrity

5.1 The Court Order Question

A natural question arises: if Stable Protocol Inc is a US corporation, can a court order compel modification of the protocol?

The honest answer requires distinguishing between what can be ordered and what can be accomplished.

5.2 What Courts Can Order

A court can order Stable Protocol Inc to:

• Write new code with specific functionality (such as address blacklisting).
• Deploy validators running that new code.
• Shut down validators we operate.
• Turn over cloud credentials.

We are subject to the jurisdiction in which we operate. We do not claim immunity from lawful legal process.

5.3 What Courts Cannot Accomplish

However, the architecture imposes constraints that no court order can overcome:

• Courts cannot change the laws of cryptography. If we deploy validators with modified code, that code has a different hash. The existing validators—running the original attested code—will reject blocks from the new validators. The network continues on the original rules.
• Courts cannot compel secret modification. Any change to validator code is cryptographically evident through attestation. Every observer can see that the code hash has changed. Covert compliance is technically impossible.
• Courts cannot modify TEE execution. Once code is running in the TEE, neither we nor the cloud providers can reach into the enclave and alter its behaviour. This is hardware isolation—enforced by silicon, not policy.
• Courts cannot erase Bitcoin anchoring. Historical state roots are committed to the Bitcoin blockchain. Past transactions cannot be altered retroactively. The forensic record is immutable.

5.4 The Practical Reality

To actually force a protocol change, one would have to:

1. Shut down every existing validator simultaneously.
2. Deploy entirely new validators with different code.
3. Restart the network with the modified software.

This is not a "modification." It is destruction and replacement. It would be completely visible—every attestation would show the change, every user would see the break in the chain. There could be no pretence of continuity.

5.5 Transparency as Protection

6. Comparison with Traditional Decentralisation Models

6.1 DAO Governance vs Cryptographic Enforcement

6.2 Anonymous Validators vs Machine Validators

7. Verifiable Infrastructure: A New Category

7.1 Beyond the Trust Spectrum

Traditional blockchain discourse presents a spectrum from "trustless" (anonymous decentralised networks) to "trusted" (single operators). Stable Protocol introduces a third category: Verifiable.

• Trustless: You don't know who operates the network, but you trust that economic incentives align behaviour. (Ethereum, Bitcoin)
• Trusted: You know exactly who operates the network, and you trust them to behave honestly. (Traditional databases, permissioned ledgers)
• Verifiable: You know exactly who operates the network, but you don't have to trust them because you can cryptographically verify everything. (Stable Protocol)

7.2 The Verification Stack

Every layer of Stable Protocol can be independently verified:

• Validator code: Attestation proves exactly what binary is running.
• Hardware environment: Attestation proves code runs in genuine TEE hardware.
• Cloud distribution: Attestations identify which cloud provider hosts each validator.
• State transitions: Cryptographic proofs validate every transaction.
• Historical state: Bitcoin anchoring provides immutable audit trail.

8. Conclusion

Stable Protocol achieves decentralisation through hardware and cryptography, not through anonymous validators or token governance.

Validators execute in Trusted Execution Environments across AWS, Azure, and Google Cloud. The TEE hardware—not Stable Protocol Inc—guarantees code integrity. We deploy the code; the hardware enforces it. We cannot modify running validators. We cannot override consensus rules. We cannot fake attestations.

Three independent cloud providers. Three independent TEE implementations. Cryptographic proof of every validator's code. No single point of control—not even us.

This architecture provides institutional users with the best of both worlds: an accountable operator they can contract with, sue, and hold responsible—combined with cryptographic guarantees that make covert misbehaviour impossible.

The Problem: Blockchain's Accountability Gap

When an institution asks "who operates your validators and what code are they running?" the honest answer for most blockchains is: "We don't know."

All blockchains provide cryptographic state verification through Merkle proofs. But Merkle proofs only verify what the state is—not who computed it, what code they ran, or whether their execution environment was compromised.

$50+ Trillion Waiting

Institutional capital remains on the sidelines because existing solutions can't provide: SOC 2 compliance, audit trails, defined SLAs, accountable operators, and verifiable execution environments.

The Solution: The Attested Blockchain

Stable Protocol introduces a new category: the Attested Blockchain. We add a second verification layer that proves how state was computed—not just what the state is.

How It Works

1. Consensus: Validators agree on transaction order (HotStuff BFT)
2. Execution: Each validator executes within hardware-isolated TEE
3. Attestation: Proofs generated showing verified code in verified environments
4. Anchoring: Attestation proofs committed to Bitcoin for immutable record

Key Features

Institutional Compliance

SOC 2, ISO 27001, and FedRAMP-ready infrastructure from day one. Known operators, audit trails, defined SLAs, and regulatory evidence through Bitcoin-anchored attestations.

Architecture Overview

Stable Protocol is an independent Layer 1 blockchain with four layers:

Not a Sidechain

Critical distinction: Stable Protocol has independent security (TEE validator network) and independent consensus (HotStuff BFT). Bitcoin serves as a notary—providing immutable timestamps—not as a security layer. If Bitcoin stopped, Stable Protocol would continue operating.

STP Token

The STP (Stable Protocol Token) is the native gas token for all network operations. Gas fees paid exclusively in STP create demand proportional to network usage.

Detailed tokenomics will be published in a separate document prior to the token generation event.

Why Stable Protocol?

The Attested Blockchain delivers:

• Cryptographic state verification (Merkle proofs — same as all blockchains)
• Bitcoin-anchored execution attestation (TEE verification — unique to Stable Protocol)
• TEE-enhanced consensus (2f+1 threshold, 1-2 second finality)
• MEV protection through hardware isolation
• Operator accountability (known validators with audit trails)
• Institutional compliance (SOC 2, ISO 27001, FedRAMP-ready)