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.

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 👇

as bitvm bridges are launching on mainnet, i've started looking into their potential implementation of security councils icydk, security councils are multisigs that can spend funds out of a given bridge instance in case of emergency. a consequence of this implementation is that we also trust the signers to not be malicious and steal funds from the bridge these types of (temporary) measures will exist as bitvm-based bridges come to market to verify their existence, we need to collaborate with bridge participants as we can't verify the entirety of the scripts unless they're used to spend funds onchain thankfully though, with the help of @ekrembal and the @citrea_xyz team, i was able to create a way to verify the spending paths for a specific BitVM testnet instance. including the security council set up this post is a summary of this process and other discussions i've had with numerous teams building bitvm-based bridges i personally view security councils as a temporary, necessary evil as these systems come to market but, i also believe that we should help users verify all trust assumptions related to bridge implementations the post suggests a few solutions. but, it'd be great to get feedback from those building in the space to determine the best path forward