Cowrie Research

fiamma-layer-primary-sources-2026-05-14

4 min read

Fiamma Layer primary-source snapshot

Collected: 2026-05-14 UTC

1) Product overview

Source: https://docs.fiammalabs.io/our-product-suite/bitvm-powered-zkp-verification-layer

Selected excerpts from the docs:

Fiamma Layer is the first-ever implementation of BitVM2, enabling ZK use cases to be verified and settled on Bitcoin for the first time.

By integrating with Babylon and implementing BitVM2, the verification/settlement layer offers both fast and hard finality, leveraging Bitcoin’s robust cryptoeconomic and network security.

Additional signals from the source:

  • Fiamma wants to be understood as a verification-and-settlement layer, not just as a bridge or generic Bitcoin appchain.
  • The fast-versus-hard-finality split is central to the mechanism and worth preserving for later comparison.
  • Bitcoin is presented less as an execution environment than as the harder final dispute and settlement anchor.

2) Core technologies page

Source: https://docs.fiammalabs.io/our-product-suite/bitvm-powered-zkp-verification-layer/introduction/core-technologies

Selected excerpts from the docs:

BitVM2 secures our ZK verification network, Fiamma, and any integrated ZK use cases with the Bitcoin network.

Fiamma leverages the Bitcoin network to settle critical disputes among our intersubjective and objective nodes via BitVM2.

Fiamma’s architecture is modular, consisting of distinct but interoperable components for execution, data availability (DA), settlement, and storage.

Additional signals from the source:

  • This page is the clearest statement that Fiamma is a modular verification stack rather than one monolithic chain.
  • The docs explicitly separate objective and intersubjective node roles before any comparison flattening can hide that distinction.
  • The universal verification network framing suggests Fiamma sees Bitcoin security as a reusable service for many outside ZK applications.

3) ZKP verification process

Source: https://docs.fiammalabs.io/our-product-suite/bitvm-powered-zkp-verification-layer/fiamma-architecture/handling-and-verification-of-zero-knowledge-proofs-and-cross-chain-interactions

Selected excerpts from the docs:

Objective Nodes: Nodes participating in the Proof-of-Stake consensus mechanism to validate proofs.

Intersubjective Nodes : User-operated nodes run on mobile devices involved in fetching, verifying, and submitting proofs.

Begin Objective Finality: The process to reach consensus on the submitted proofs begins.

Begin Intersubjective Finality: The process for final validation involving intersubjective nodes begins.

If the proof is invalid, the unhappy path is triggered.

Additional signals from the source:

  • This page contains the key architectural split: proof handling first passes through objective validation, then through broader intersubjective checking.
  • The happy-path / unhappy-path distinction is analytically important because it shows where slashing, Bitcoin checkpoints, and stronger settlement guarantees enter.
  • The docs make clear that applications may act on soft finality before the Bitcoin-secured dispute path finishes, which is a major control-plane question for future comparisons.

4) Validator / staker guide

Source: https://docs.fiammalabs.io/our-product-suite/bitvm-powered-zkp-verification-layer/developer-guides/run-a-fiamma-node/become-a-bitvm-staker

Selected excerpts from the docs:

On the current testnet, users who need to register as Fiamma validators must be approved before they are allowed to create one.

You have submitted your registration application.

wait the Bitcoin transaction is confimed, we have successfully register validator_key as BitVM staker.

Additional signals from the source:

  • The current validator-admission path is not fully open, which matters when judging present decentralization versus future design intent.
  • The guide ties validator registration to a Bitcoin transaction flow, making the BitVM/Bitcoin settlement path operational rather than purely conceptual.
  • This is a useful maturity caveat: the reviewed system is still staged and partially permissioned in testnet form.

5) Roadmap

Source: https://docs.fiammalabs.io/our-product-suite/bitvm-powered-zkp-verification-layer/roadmap

Selected excerpts from the docs:

Enable ZKP Verification on Mobile Nodes

Integration with Babylon & BitVM2 (Consensus)

Allow Staking of Nodes and General Users

Activate Intersubjective Slashing

Additional signals from the source:

  • The roadmap reinforces that mobile-node verification and intersubjective slashing are core to the intended design, not side experiments.
  • It also shows that some of the strongest decentralization claims are still roadmap items rather than already-complete production features.
  • For corpus purposes, that makes Fiamma more valuable as a mechanism comparison point than as a proven finished deployment.

Notes

  • Fiamma Layer is worth cataloging because it isolates a different Bitcoin-secured design family: fast proof acceptance through one validator path, then user-checkable dispute escalation toward harder settlement on Bitcoin.
  • The main control surfaces to track are objective-node admission, intersubjective-node participation, the threshold for moving from soft to hard finality, and how much trust downstream apps place in the earlier stage.
  • The biggest comparison payoff is against proof-verifier chains, AVS / attestation systems, and BitVM-branded bridge or settlement stacks that talk about Bitcoin security without exposing such a clear multi-stage validation split.

Graph View