I am reading about side-chains, and what I read in this article is:

The initial sidechain included in Sidechain Elements works on a federated security model; while it’s still peer-to-peer and consensus-based, security for the blockchain is provided by a set of predefined functionaries in an arrangement called a Fed-Peg. A number of academic groups and individual contributors have agreed to run the Sidechain Elements Fed-Peg, including blockchain groups at Stanford, MIT, and Princeton. The sidechain does not include mining or proof-of-work at this point.

I have no idea what that means. What is "fed-peg"? Why is that needed? Does it change in any way the security of the main chain? How does it differ from decentralized PoW?

4 Answers 4


I have no idea what that means. What is "fed-peg"? Why is that needed?

When you're creating a sidechain, you need a way to move Bitcoins from the main network to your sidechain. This is pretty straightforward. Counterparty, Ethereum, and NXT had various ways of doing this. (Admittedly, none of these allowed people to turn Bitcoin into the assets on these networks after they started, but I suspect that's due to economic reasons rather than technical ones.)

The more complicated, and more important issue, is how you move Bitcoins that are on the sidechain back into the main network. I've heard multiple proposals on how to do this, but all of them are either

  • insecure,
  • centralized,
  • or require very complicated changes to the Bitcoin protocol.

This approach is centralized.

The idea with that you have several authorities, each of whom has a private key. Those private keys together control a multisignature account. When you move Bitcoins onto the sidechain, you deposit them into the multisignature account. When you want to move them back to the main chain, you do so on the sidechain; those federated authorities will independently validate that transaction. Then, all of them sign a withdrawal from the multisignature account to the main network address you specified in your sidechain transaction.

The blockstream paper suggests a 3 of 5 multisignature account. The issue with this is that if 3 of those keys are compromised (or if 3 of them collude) then they can take all of the money out of the multisignature account.

Does it change in any way the security of the main chain?

No. It doesn't modify the main network. Future incarnations might, though. There's not enough detail about those possible future systems to answer that at present.

How does it differ from decentralized PoW?

The federated authorities have two roles in this system: gating transactions into the system by producing timestamped blocks, (something normally done by miners) and the previously mentioned multisignature account.


Federated peg is described in Appendix A of the sidechain whitepaper, https://blockstream.com/sidechains.pdf . I don't completely understand the details but here is an overview. In order to implement sidechains in the ideal fashion, the Bitcoin protocol must be modified. It is difficult to gain consensus for such a modification. However, in the meantime, "federated peg" is proposed as a temporary measure for implementing sidechains.

The idea of sidechains is to set up a system that allows you to effectively transfer Bitcoins from the main chain onto the sidechain, and then later transfer those Bitcoins back from the sidechain onto the main chain. While the Bitcoins are 'effectively' in the sidechain, from the perspective of the main chain they are just sitting in some address ('locked'). I like to imagine that the 'locked' Bitcoins on the main chain are 'sleeping' deep in a trance, projecting their 'astral body' into the 'astral plane' of the sidechain. When they finish their business on the sidechain they can then later 'return to their body' and 'wake up' on the main chain.

With federated peg, in order to transfer the Bitcoins from the main chain to the sidechain, you transfer it to an address on the main chain and give control of that address to a small set of trusted parties using a multisignature transaction (eg perhaps you choose 5 trusted parties and then use a 3 of 5 multisig; then in order to move the coins back to the main chain, 3 out of 5 of them will have to agree). These trusted third parties are called 'functionaries' in the paper.

Then, on the sidechain, the trusted third parties inform the sidechain that you have just transferred in those Bitcoins. The 'astral bodies' of your Bitcoins can then be transferred to others on the sidechain. Perhaps at some time in the future, a future owner of some or all of these 'astral bodies' wants to move them back to the main chain. This person informs the trusted third parties (the functionaries) of the main chain address that e wishes to send the coins to, and attaches a proof-of-ownership showing that they are the current owner of the 'astral bodies' on the sidechain. The functionaries inspect the proof-of-ownership and if it is valid, they then delete (or otherwise remove from circulation) the astral bodies from the sidechain, and use their multisignature authority on the 'locked' coins on the main chain to unlock them and send them to the requested address.

This method is called 'federated peg', presumably because it is a type of 'peg' (connection between coins on the main chain and coins on the sidechain) enforced by a 'federation' of trusted third parties (functionaries). This method requires trust in the trusted third parties (functionaries) because if 3 of 5 of them collude (or however many of them there are), or get their keys stolen, then the 'locked' Bitcoins can be stolen on the main chain. However, the goal is for this to just be a temporary measure, until such time as consensus is gained to modify the Bitcoin protocol to implement sidechains using a different method, called 'SPV peg'. After that, you would be able to stop using 'federated peg' and use 'SPV peg' instead; unlike federated peg, SPV peg allows you to transfer Bitcoins between chains without trusting anyone.

'Federated peg' does not modify the Bitcoin protocol or require the cooperation (or even knowledge) of anyone outside of the users of the sidechain, so it has no impact on the security of the main chain.


It means that, unfortunately, they still can't figure out how to make a sidechain work without either a central authority or its own independently-mined chain (i.e. a full-fledged altcoin).

This is sad, because it was the one thing they kept promising sidechains would bring us.

But yet we're still back where we started: if you want a cryptocurrency with a feature bitcoin doesn't have, and you don't want a central trusted authority (like Ripple), you need to start an altcoin. Sidechains have not changed anything here.

  • Well, I still don't understand what does it actually mean and how is the pegging done. Jun 9, 2015 at 16:42
  • Well there's a trusted third party whose public key is hardwired into the code. Any difficult questions that come up or disagreements, basically the trusted party decides the answer. Same as Ripple pretty much. Jun 9, 2015 at 16:44
  • Here, check out github.com/ElementsProject/elements/blob/alpha/contrib/fedpeg/… -- basically you must "rippleize" the sidechain by hardwiring its central authority's public key on line 15. Without it, no sidechain. Jun 9, 2015 at 16:57
  • I think that's why they started lightning.. because they weren't getting anywhere with sidechains.. and now we have to bear their blocking of the block size increase.. -.-
    – tobi
    Oct 18, 2015 at 20:16
  • Afaict it's not that they "can't figure out" how to make sidechains work without a central authority, it's just that their primary proposal (SPV peg) requires a modification to the Bitcoin protocol, which requires gaining consensus. So, as a temporary solution in the meantime, they propose "federated peg". The plan outlined in the paper is to persuade others of the safety and desirability of SPV peg and then switch to that later. (I am not taking a position on whether an SPV peg is actually safe and desirable, I'm just saying that the paper presents it as such).
    – bshanks
    Nov 2, 2015 at 4:41

A tiny bit of detail on this was added as an "Appendix A" to the sidechains paper at some point:

By adopting some additional security assumptions at the expense of the low trust design objective, it is possible to do an initial deployment in a completely permissionless way. The key observation is that any enhancement to Bitcoin Script can be implemented externally by having a trusted federation of mutually distrusting functionaries evaluate the script and accept by signing for an ordinary multisignature script. That is, the functionaries act as a protocol adaptor by evaluating the same rules we would have wanted Bitcoin to evaluate, but cannot for lack of script enhancements. Using this we can achieve a federated peg.

Basically it's a cabal of "trusted miners".

Since the main bitcoin chain miners don't understand the sidechain's cool new features they can't validate those blocks. So the sidechain has to be run Ripple-style where there is a pool of trusted miners and one of them has to sign off on each block. These trusted miners (which they call "functionaries") hold special private keys, and the corresponding public keys are hardwired into the source code. These central authorities have the power to block the chain's progress, exclude transactions, or even freeze accounts.

  • 1
    Is there some reason why you made two answers instead of editing your first answer?
    – Nick ODell
    Jun 9, 2015 at 19:10
  • @NickODell it enables him/her to "sidechain" his answer. Oct 19, 2019 at 5:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.