# RSKIP567: Fork-Aware Consensus **URL:** \ **Category:** RSKIP\ **Created:** [September 16, 2026, 12:55pm UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551 "2026-09-16T12:55:15Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![darcy.camargo](https://avatars.discourse-cdn.com/v4/letter/d/59ef9b/32.png) [@darcy.camargo](https://research.rsk.dev/u/darcy.camargo)\ **Post date:** [September 16, 2026, 12:55pm UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551/1 "2026-09-16T12:55:15Z")
As an effort to communicate better the research done and to open the space for criticism and discussions, I plan going forward to create a topic here for each topic that I work on. To bootstrap this, I will share the RSKIP that I worked last quarter and updated this quarter: Fork-Aware Consensus. This is based on Sergio’s series of proposals to improve fork detection. [RSKIP link.](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP567.md) Following here a quick summary to those who can’t open the link. **What is Fork-Aware Consensus?** It is a possible replacement for Armadillo where we take the idea of verifying RSK tags from the Armadillo node on BTC to each RSK node instead. To do this, we change the extendedData field on RSK block headers to include a new element carrying data from BTC coinbase transactions. We call this extension the Fork-Balance Proof. **What is Included in the Fork-Balance Proof?** Take any RSK block A, merged-mined with BTC block B (not necessarily broadcast on the BTC network due to difficulty). We include in A’s Fork-Balance Proof the last bytes of the coinbase transaction included in the PARENT BLOCK of B, as well as other fields to prove that these bytes are correct, belong to the correct block and that this block is indeed B’s parent. **What is the logic behind detection?** The logic is the same as Armadillo: We look for tags that include the hash of blocks we cannot identify in the canonical chain (+uncles). The difference is that we check this continuously for each block and build a metric based on the proportion of these tags we find. When this proportion is above a certain threshold, we trigger a flag on blocks to signal that a hidden fork is very likely to exist. **What users/nodes do with this information?** The main objective of fork-aware consensus is to bring awareness to the user. We don’t expect them to filter blocks, but we expect them to hold on high value or sensitive transactions, and perhaps delay confirmation using this information, cutting incentives to the possible attacker. Finally, this is not implemented yet and it can coexist with Armadillo as long as we need, so the project may change over time. ---
**Author:** ![Nuh](https://avatars.discourse-cdn.com/v4/letter/n/da6949/32.png) [@Nuh](https://research.rsk.dev/u/Nuh)\ **Post date:** [September 16, 2026, 2:03pm UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551/2 "2026-09-16T14:03:39Z")
Thank you very much for this, and I am already excited for superchains discussion as well. I see the RSKIP has been updated with more details and graphs, so I will spend some time reading this update. However, my main question has always been; why not just implement Armadillo in RSKj? Is it really that hard to implement a Bitcoin SPV in RSKj? Yes I am usually pushing for RSKj to embrace being a sidechain and not independent blockhain, but I also think Rootstock headers are too big already, and I would rather to remove fields from it not add to it. Also any scheme that can make IBD faster (without super expensive and possibly buggy ZK clients) would require that we already watch Bitcoin chain, so I think adding the same data in `extendedData` is redundant. Is there something in RSKj codebase or consensus assumption that makes this RSKIP easier to deploy than just shipping Armadillo in RSKj? ---
**Author:** ![darcy.camargo](https://avatars.discourse-cdn.com/v4/letter/d/59ef9b/32.png) [@darcy.camargo](https://research.rsk.dev/u/darcy.camargo)\ **Post date:** [September 17, 2026, 1:43pm UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551/3 "2026-09-17T13:43:15Z")
Hi Nuh! Thanks a lot for the comments. The problem with Armadillo is that as it is designed, it is a centralization point with a problem of incentives. It does not really align well with the design we want to put all security against hidden forks on the back of the node running this. Also, trying to create something like “Committee-based Armadillo” would just create fees and a complex design that more failure points. It would feel like a patch more than a solution. About the extensive header, if RSK nodes had to also run a BTC node, then this field would indeed be redundant, but this a deeper design choice that involves the whole protocol, so I can’t really do much about it. ---
**Author:** ![Nuh](https://avatars.discourse-cdn.com/v4/letter/n/da6949/32.png) [@Nuh](https://research.rsk.dev/u/Nuh)\ **Post date:** [September 17, 2026, 10:33pm UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551/4 "2026-09-17T22:33:18Z")
I don’t think RSK nodes need to run BTC nodes, just download headers and coinbase transactions, Rootstock is already aware of headers using a precompiled smart contract, if I am not mistaken. So I don’t see that expecting RSKj to gossip bitcoin headers and coinbase txns to be very radicle, and it could be part of this RSKIP, the other part remains the definition of SAFE tag. I might be mistaken, in which case I would hope someone explain to us why can’t RSK nodes be aware of the BTC headers and coinbase txns. ---
**Author:** ![GoldenGatsby](https://yyz2.discourse-cdn.com/flex036/user_avatar/research.rsk.dev/goldengatsby/32/196_2.png) [@GoldenGatsby](https://research.rsk.dev/u/GoldenGatsby)\ **Post date:** [September 22, 2026, 2:42pm UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551/5 "2026-09-22T14:42:44Z")
Great to see you posting here Darcy! I will familiarise myself with the latest updates for the RSKIP now. ---
**Author:** ![Nuh](https://avatars.discourse-cdn.com/v4/letter/n/da6949/32.png) [@Nuh](https://research.rsk.dev/u/Nuh)\ **Post date:** [October 16, 2026, 7:49am UTC](https://research.rsk.dev/t/rskip567-fork-aware-consensus/551/6 "2026-10-16T07:49:18Z")
Now that I am actually wrestling with building a rootstock light node according to Ephemeral Sidechain ideas, I realized that having bitcoin coinbase transactions in Rootstock headers is useful, because bitcoin p2p wire doesn’t allow you to ask for the coinbase txn + proof, you have to either download the entire block, or add another dependency in the form of Electrum server that gives you the coinbase txn. Do we have any timeline on FACON? I assume next upgrade, so at least a year? Edit: some bitcoin peers still support bloom filters so maybe that will work for me, but these peers will disappear as more people upgrade to latest bitcoin core.