my initial review on @citrea_xyz can be found below janusz.cash/layers/citrea tl;dr: citrea is a bitcoin sidesystem that uses bitcoin for data availability making it a bitcoin rollup it is an independent network with its own full node software. citrea advances its state by applying state transition logic over a set of transactions posted to bitcoin by the citrea operator (known as a sequencer) citrea full nodes initially gather blocks directly from the sequencer, execute them, and generate a new state root the sequencer then posts differences in state to bitcoin and full nodes verify that the state update posted to bitcoin matches the state they generated locally and every so often, a prover posts a validity proof to prove that the state transitions were executed correctly to finalize the full nodes view of the rollup as well as light clients to move bitcoin onto the network, citrea uses the clementine bridge which is an implementation of bitvm2 the clementine bridge vault has two primary spend paths the first sees 10, institutional signers, who participate in a 10-of-10 multisig set up, collectively spend funds out of the bridge vault contract to process withdrawals in the happy path clementine also contains an additional spend path where a 3-of-5 security council can spend funds out of the bridge vault contract in the event of one of the signers being unresponsive, or malicious, citrea leverages a bitvm-style game to enable operator-fronted withdrawals an operator kicks off the bitvm game by requesting a reimbursement transaction. in the transactions i analyzed, the kick off transaction was followed by two transactions where the corresponding utxo was spent by 1) a presigned tx spendable by the aggregate musig2 key from the clementine signers or 2) the clementine security council both script trees also contained an unrevealed path which most certainly contains the presigned transaction tree for the clementine bitvm protocol citrea is the first implementation of a bitcoin rollup, with an official bridge program, on bitcoin mainnet based on my findings, it does in fact use a bitvm-style protocol as outlined in its documentation site the network has training wheels on, but it's extremely promising to finally have a bitcoin rollup on mainnet with a verifying bridge!

some news: @blockspace has acquired @BitcoinLayers the acquisition will enable bitcoin layers to expand its data capabilities we already have some great progress on this front courtesy of @khunpleb we’ll also be working on revamping the research portal and expanding it past bitcoin l2s and bitcoin-backed assets truthfully, it will be a 10x on what we were doing before i’m excited to work with @cbspears, @wsfoxley, and co. to get bitcoin layers to where it should’ve always been i do want to thank everyone; the l2 teams, crypto projects, various conferences, and ecosystem friends for giving us a chance at building a neutral platform for this emerging category and i want to thank @redvelvetzip for joining me on this journey. i also want to specifically thank @alexeiZamyatin and @0x_orkun for giving me the motivation & confidence to start the project over two years ago and personally supporting me during the early days

what i see as the main difference between @arkade_os and @flashnet let's say a user has an offchain utxo (leaf or vutxo) and wants to do some crazy shit to support this, flashnet uses an intent model where users send funds to an address controlled by validators. if intent is valid, the validators take a key share and pass it to the flashnet signer. if m-of-n validators pass the key share for the intent, the signer executes the transaction arkade extends their virtual mempool to support co-signing for more complex scripts. i.e., the arkade signer is able to sign off on things more complex than bitcoin scripts. a user needs to co-sign this execution, but model requires an honest signer for all offchain actions (like any out-of-round transaction) flashnet is an "at execution" custody risk. after execution, (in most scenarios) a user returns to a statechain model, meaning they have a pre-signed exit path for their utxo arkade has users remain in a "preconfirmed" state during all of this execution. post-execution, they can participate in a settlement transaction on bitcoin to gain full self-custody of their funds both models use TEEs for signing execution in flashnet, m-of-n validators need to collude and/or the TEE signer needs to be compromised to steal user funds in arkade, the TEE needs to be compromised and previous owners within a specific vtxo tx chain need to collude with the TEE i don't know which is *better* - just a different approach

someone asked for a @BitcoinLayers review on @arkade_os. i'll do it later but tl;dr custody - green tx data - green operator - dark red finality - green or yellow very good. congrats team

psa: most of the popular LSTs and new bitvm bridges are not open-source and we can't verify the claims that teams make in their documentation sites many such cases of "trust me bro"

bitcoin l2 buckets self-custodial: lightning, ark (@arkade_os, @secondhq). users have pre-defined exit paths and can finalize state updates/publish final state onchain unilateral exit but no finality: statechains (@spark). spark lacks finality as operators can't prove key deletion, but users have predefined exit paths rollups: @citrea_xyz, @AlpenLabs. since blobs are posted to bitcoin, rollups can finalize their state based on data made available by bitcoin full nodes. however, since script is limited, we cannot build a trust-minimized two-way peg like ethereum rollups can (right now at least, maybe something else gets discovered). basically, they can be better implementations of sidechains where users can run a rollup full node based on data from their bitcoin full node sidechains: multisigs. nothing different than what's been around for years. they're alternative l1s that may have some connection to bitcoin (e.g. a post state root). they can be their own PoS system, be merge-mined, or something else. may have an official bridge which can be federated (permissioned like @stacks) or based on PoS validator stake (semi-permissioned like @nomicbtc) alternative l1s: the same thing as sidechains but they don't call themselves a bitcoin l2 on twitter chains with bitcoin staking: depends on the implementation. some systems have bitcoin stake influence their validator weights, others use for additional finality signatures. imo checkpointing provides more security for alternative l1s than current bitcoin staking implementations. bitcoin staking doesn't provide "bitcoin finality", checkpointing does. rollups to other chains: they're just rollups to other blockchains and inherit security from the other blockchains' consensus set. they may have a bridge to bitcoin. they may post a state root to bitcoin. security is still from DA layer. other things: some chains enable users to batch intents to another PoS blockchain and have that validator set execute intents. users trust the validator set during the time its executing their intents started researching this stuff two years ago. the definition of an l2 has never changed, just people trying to change it. lots of exciting things happening within the ecosystem. although, it's a pretty small group of teams really pushing the boundaries. being an l2 doesn't matter, it's more about your app strategy. existing l1s probably have an upperhand over bitcoin sidechains and such, but every ecosystem is one app away from popping off. most of the yield games are a scam. most, if not all, of the token launches are a scam. CT thinks bitcoin "l2s" as a category are dead. treasuries and bitcoin wrappers on other chains are more interesting. they're probably right, but it's still a category worth building. i have hope in a few teams that they can make a dent in the ecosystem.

It’s stupid, but @spark is literally bitcoin. Just a bit faster A few months ago, I gave a talk on Spark at @citrea_xyz’s research day event. During the Q&A section of the event, someone asked me: “Can systems like Spark enable more programmability?” I hand waved a bit. Honestly, I didn’t know the answer. I had heard of “smart contract layers” coming to Spark, but I had no idea what they could do or how they worked. Fast forward a few months, @flashnet launched their beta. With that launch, docs were made password accessible, so I had a look. Basically, Flashnet is a layer that is built on top of Spark. It takes user intents from Spark users, matches them, executes the intents, and then distributes the funds back to users. During this execution of intents, Flashnet validators take temporary custody of funds in a shared “multisig” address. After the intent is executed (in seconds), users are given their updated balance post execution. While reading this, I came to the realization that it's similar to the way that “smart contract layers” on bitcoin work. But Flashnet is built on Spark, not bitcoin directly. And since Spark has sub-second transaction finalization, matching of user intents (trades, etc.) happens infinitely faster. I’ve been thinking about the “developer moat” for bitcoin L2s lately, and Spark’s is very clear. Most (if not all) of the token transfer, bitcoin-native metaprotocol-like applications that developers build on bitcoin, can also be built on Spark. Due to its statechain architecture, teams can argue (pretty soundly I might add) that user funds are self-custodial or non-custodial. And because Spark only operates via exchanging ownership of L1 bitcoin UTXOs, users do not have to “bridge funds” onto Spark. This is certainly a worthwhile tradeoff. Now, some applications might come with greater trust assumptions, just as Flashnet does. But, the finalization of these transactions happens at a much faster pace, so users’ exposure to the trust assumptions can be minimized from a time perspective. This is Spark's moat. So if you can build it on bitcoin, you can build it on Spark. I’ve written a lot about the trust assumptions related to the protocol, so check out the @BitcoinLayers review below to learn more. If you are fine with these trust assumptions (they’re pretty reasonable in my opinion), then Spark has a great developer moat to build solana-speed applications, where users retain strong custody assumptions and can incur further assumptions per their individual, application-specific use case.

what's a better custody assumption 1) a rollup (like @AlpenLabs) with a BitVM instance. upgrade mechanism is executable by a federation (6/9 let's say) and is bound to a timelock 2) statechain (like @spark) where the statechain entity with a 3/3 signing threshold

thought exercise this morning when people say "self custodial" l2, then mean that a user can: - spend the funds on bitcoin - have the data needed to spend funds or contest fraud - proof that they're the only ones who can spend the funds if you don't have all three, then you don't have provable self-custody and therefore are not an "L2" by a really strict definition the only protocols that can have these guarantees are lightning and ark. rollups could also have this guarantee if we did a few soft forks. i think protocols like shielded csv could as well (in the event of a soft fork) statechains don't have provable key deletion, so even if a user does have custody, they can't be sure they are the only ones who do (fwiw, I disagree with this entire post because i think statechains are l2s) now, custodial. this is a spectrum sidechains are custodial. you do not have custody of funds in the sidechain model, but the custody can be distributed across a number of nodes for example, signers in a two-way peg can be all of the sidechain validators themselves. this is certainly decentralized and can be a good model. you can even argue its superior to being an L2 but, it's still "custodial". it's just that the risk is distributed across many validators and even in things like chaumian ecash, multi-mint payments let users disperse custody risk across a number of mints wrappers, in practice, are really centralized but can also have distributed custody models (e.g. a blockchain that is designated for custody i.e. nomic) so when we say custodian... we still need to analyze the custodian(s) and how users interact with them being an l2 isn't necessarily the best thing. the thread below though, however, does shed light on what people mean when they say "technically an L2" 🙂

finally back to writing reviews for @BitcoinLayers goal 👉 use our database (over 500 bitcoin-backed tokens on alt networks and more coming) to directly import analysis on their governance structures in the reviews also am working on more granular analysis for bitcoin native networks such as spark and ark implementations i've got 50 hours worth of flights over the next 6 days, so hopefully will make a lot of progress adding the necessary infra took a bit longer than i expected, but it's a good place

the enforcement of finality for an alternative blockchain is not provided by bitcoin checkpointing has its benefits, but they are always enforceable by the the alternative consensus network, not bitcoin the term "settlement layer" does not apply to alternative blockchains, from rollups to sidechain explained my opinion below 👇