2つの類似プロジェクト（PikachuとNomic）と比較しながら、Babylonがどのように自身のチェックポイントをBitcoinにマッピングするかを整理する。Babylon自身の資料では、比較対象として両方が挙げられている。

Babylonの方式では、バリデータが各PoSブロックのダイジェストに署名し、1人のリレイヤがBLSで署名を集約したうえで、OP RETURNを使ってすべてをBitcoinトランザクションにパッケージする。

チェックポイントごとにトランザクションは2件で、少なくとも1つのOP RETURN出力を含む。それらは、受信側eNdでTrustless Bitcoin Vaults（TBV）のTBVスタイルのライトクライアント証明に対して検証される。

Filecoin向けにProtocol Labsが作ったPikachuも同様のOP RETURNアプローチを採用しているが、Babylonのブログでは、自身のバージョンは比較対象と比べてよりシンプルで、よりタイムリーで、より柔軟だと具体的に述べている。

Nomicは別のルートを取る。このチェックポイント方式を、一般的なPoSセキュリティのためではなく、nBTCトークンの裏付けとなるBitcoinを管理するために特化している。

ただし、OP RETURNベースのすべてのアプローチに共通する実際の制約が1つある。BitcoinはOPRETURNデータを80バイトに制限しているため、バリデータ集合が増えると、チェックポイント用トランザクション数のカウントが参加するバリデータ数に応じて線形に増えていく。

つまり、この設計上のトレードオフは、3つの間で「より良い／より悪い」という話ではなく、それぞれが何を最適化しているかの違いだ。BabylonはFilecoinにおける一般的なPoSセキュリティ、Pikachuはその比較対象として、Nomicはラップされたトークンの裏付けのために最適化している。$SKY $BLESS $BIO