
Tech • IA • Crypto
Developers say Liquid, a Bitcoin sidechain, lagged adoption due to poor usability and tooling, but new features and real-world use cases may drive renewed growth.
Liquid, launched by Blockstream in 2018, offers features like confidential transactions, multi-asset issuance, and advanced scripting. Despite early hype, usage has remained limited. Developers argue the gap stems less from capability and more from difficulty turning those capabilities into usable products.
For years, Liquid suffered from weak or missing developer documentation and minimal outreach. Critical infrastructure such as wallet guidance and tooling was underdeveloped, leaving builders without clear pathways to create applications. This slowed ecosystem growth even as the protocol itself advanced.
Features like confidential transactions require managing additional cryptographic data for every input and output. This makes multi-party transactions significantly more complex than standard Bitcoin transactions. Without accessible tooling, these complexities discouraged adoption.
Liquid introduced extended scripting capabilities, including covenants and opcodes like OP_CAT, but these were difficult to use in practice. Limitations such as opcode caps and unintuitive design made early smart contract development nearly unworkable, delaying real-world applications.
The introduction of Simplicity, a more expressive smart contract language, marks a turning point. After years of development, it enables more robust financial applications, though it remains technically challenging. Developers are now focusing on abstracting this complexity away from end users.
Projects like Sideswap are building wallet integrations similar to “connect wallet” systems seen in other ecosystems. These tools allow users to interact with advanced contracts through simple interfaces, hiding the underlying complexity and enabling broader participation.
Organic usage is increasing, notably in Brazil, where a local stablecoin and USDT on Liquid are driving activity. This positions Liquid as a practical platform for Bitcoin-based financial services, particularly in regions with high demand for dollar-linked assets.
Liquid’s UTXO model complicates designs like automated market makers (AMMs), which are common in Ethereum. Issues such as transaction ordering, lack of global state storage, and front-running risks require alternative architectures, often relying on off-chain coordination or bulletin-board systems.
Builders are experimenting with non-custodial prediction markets, options-like instruments, and atomic swaps. Early versions require users to hold positions until maturity, highlighting ongoing limitations. However, developers believe liquidity and tradability features can be added over time.
Liquid’s slow start reflects usability and ecosystem gaps rather than technical weakness, and ongoing improvements in tooling, user experience, and real-world adoption may determine whether it becomes a meaningful layer for Bitcoin-based finance.
What is up, Vegas? How's it going, guys? >> We got a full house in here. Um, vibes are high. We have a great conversation lined up. Last time I interviewed Andrew, I asked him a single question and he told a 30-minut story and then we both walked off stage together. So, we're going to start with Scott today. Scott is uh is the founder of Sides Swap. He's building financial services tools, self-custody financial services tools on Liquid. Um Liquid is one of those projects that I find fascinating. It always seems technically intriguing. Uh but in practice, we haven't really seen much usage of it. Um, I think Sides Swap is probably the single best liquid app experience I've ever played with and I've ever used. So, Scott, on that topic, when you're building out Sides Swap and the other tools that you're building out right now, how do you think about liquid and liquid adoption? And and why do you think we haven't seen the kind of usage that maybe the hype would have you believed like five years ago, six years ago? There's a very good question. It's the one we were always struggling with in terms of how we can bring more people into liquid. I think when the SegWit discussion was raging, uh probably uh Liquid took a bit of a beating during it. But in terms of the tech stack, in terms of what we hope to accomplish, I think Liquid has all the tools to be able to build a Bitcoin based financial system with multiple asset issuance and everything else around it. And now with the simplicity coming, there's so many more tools coming online uh enabling us to truly build all of these products like prediction markets, etc. So yeah, we're super excited. We've been growing organically for quite some time and uh I think adoption is finally growing. there's a big adoption coming from um Brazil right now with a stable coin being issued there and liquid having USDT on the chain is like a very big win for Liquid and makes it the default Bitcoin side chain to work on since it has USDT. >> Yeah, I mean the the Brazilian adoption is fascinating because it's it's been relatively organic. I mean we had a conversation earlier um where like kind of caught you off guard. you didn't even you you didn't manufacture that. The users came and then you embraced them. Um I mean Andrew to that point I mean I didn't introduce Andrew. Andrew is one of our Bitcoin wizards uh that uh we're very fortunate to have building in the Bitcoin space. I mean you guys put at Blockstream you guys put a lot of work into liquid. in your opinion, why hasn't the adoption necessarily lived up to the hype? >> I can give a couple of answers to that. Right. So, one one issue that we've had continuously until quite recently is we've been pretty poor at communicating. Um, it's nice of of Scott to say all these nice things about having all the tools you need and building this, but our developer documentation for many years was basically missing or atrocious or or out ofd. uh our developer outreach really we we basically weren't focusing on developers and I can take some responsibility for this because I I was uh for most of Liquid's life I was the director of research at Blockstream and I was kind of responsible for spearheading much of the technology that we were putting into liquid but as we were building technology that goes into liquid the blockchain we were thinking about what can we implement in a node what can we verify efficiently like what cool crypto can we pull together and verify efficiently. And the question of well, how do you actually use this? Well, that's a problem for the wallet developers who were I don't know, we didn't think about who the wallet developers were. It largely wasn't us. And we didn't provide wallet developers the information they would need to build this. And it turned out there's a lot of hard problems actually in developing wallets. Um, some of which Scott might talk about um about how to handle multiple assets that have like interesting semantic meaning when you're attaching scripts and stuff. and some like crypto issues, right? So, we developed this thing called confidential transactions on liquid, which was one of our like headlining features of this blockchain that we could hide all of the amounts and all of the asset types in all your transactions without adding some ever growing accumulator thing without having all these asmtoic scaling problems that Zcash had. Well, in order to do that, you effectively need to manipulate this extra secret key data for every single input and output in your transaction. So, if you're trying to do a multi-party transaction, you now have to do some crazy multi-party crypto protocol instead of just passing a transaction around and signing it. We never really worked through that problem. We didn't provide the the the documentation to uh to even start working through it. And we were kind of focused on on building other stuff. So, that's one answer. I have one other answer which is in terms of scripting capability, it's kind kind of more of the same thing, right? Uh when liquid was launched, we extended we took Bitcoin script, we extended it to provide covenants. We added opcat, everyone's favorite op code, uh and checks from stack. And together those two allow you to do covenants, basically arbitrary contracts that have multiple stages and and all this cool stuff. And we added kind of a a halfbaked collection of other op codes that that aren't so interesting. And we published a few blog posts. Here's how you build covenants and so on. Uh and threw it out there. see is anybody going to take our blog post blog post and try to build something. Well, some years later, we actually did within Blockstream Research start building options and financial products with this and we immediately ran into like this 201 O op code limit that we forgot to remove and like a bunch of other weird pain points that made this extremely difficult to do. So, we frantically updated to tap routt which conveniently removes a whole bunch of script limits and other stuff. Also, everybody's favorite change to Bitcoin. I know. Um, so that got us past all of these limits and now we at least could use these op codes to build cool stuff, but it was really we couldn't reason about it. It was such a head headbending thing to try to build smart contracts this way. Um, and we it just it just basically didn't work. So then we started prioritizing Simplicity, which we'd been working on without launching for like 10 years, and we're like, okay, now we need like a serious smart launching language. Let's let's put Simplicity out there. We made a huge push. We uh we cleaned everything up. We got everything polished and production ready and tested. Launched it on Liquid. Well, that was only like a year ago, 18 months ago or something. Liquid's been around since 2018, right? And this whole time we've been hyping up a confidential transaction system that wallets don't know how to use, an expressive scripting system that actually is basically impossible to use. Um then a pile of other features we failed to communicate. So over the last year, over the last two years, we've uh kind of come to terms with these problems. Um and Blockstream has has done kind of the right thing in in hiring a lot of people who are not me to work on these things because I this is not my core competency is is making things people can use and explaining how to use them. I I think I took a long time to come to terms with that and I I guess the company as well. So >> So maybe if somebody could try to spin that positively for me. I mean, it's going to be a hard one, but uh we made it. I um I don't see him in the audience, but I just real quick huge shout out to Francis and Pedro because the the live Zaps is really fucking cool. I don't know. I think that's a really awesome situation. Maybe I'm just a fucking nerd. I will say uh to anyone who's listening from the BTC Mag team, it'd be great if I could see the Zaps up here next year. It could be, wouldn't it be awesome if you just saw people throwing money at us? Um, but anyway, thank you for your support who's ever zapping because I can't see. Um, Scott, to Andrew's point, like what are you excited about in terms of building with simplicity? I mean, the crazy thing to me about simplicity is it's it's actually very complicated. Um, so I the name is is is misleading, but how how do you think about uh so it's a hard thing for me to wrap my head around. What is what is the the enduser experience that you think you can build with something like that? >> Again, a great question because there's, you know, so many things to figure out. Uh so the first thing that we did was we built this uh liquid connection function uh where web pages can uh connect to our wallet so that the web page uh when you build these different products which use simplicity so that you're able to create the transactions and uh have everyone interact with each other because the the whole premise is that it's non-custodial and since you need multiple parties to join in and create transactions together etc. You need a way for everyone to communicate with each other. And to make that efficient, we built this um liquid connect function which basically just connects the wallet. But but then over and above that you uh you obviously need to build a simplicity products which people will use. Uh so the UX is very important to make the function easy so that they can actually connect to any web page like meta mask type of connection or connect wallet and once they have that to make the interaction on the web page as easy as possible. So in a sense you need to obiscate um quite a bit of the flow to the user and the liquid connect function will will have effectively the ability to uh see a watching only wallet of watching only copy of the wallet so they can create all the inputs and outputs for the transactions. Uh but once the user gets onto the web page uh they don't really interact with the simplicity scripts themselves. Everything runs in the background. So you can obiscate a lot of it in the UI. So it becomes a point and click just sign the transaction and once you uh have placed the prediction that you want. Anyone who's looked at any of the prediction market pages, it very much works the same way. And once you click the button, uh you'll receive in your app the transaction notifications. You can review everything in the app. Does it make sense? And then you sign in the app and it goes back. Yeah, there's a couple cool technical problems that that Scott kind of glossed over in describing this Liquid Connect thing. And a big one is that liquid has no bulletin board, right? So if you're building smart contracts in the Ethereum ecosystem, there's kind of a culture and and a lot of technical support for if you need to store state, if you need to store data, if you need to store whatever, just throw it into your contract code and you they have sort of a payment system, but and we can argue about the whe whether this is incentive in line, but essentially every single node for every single contract maintains this giant lookup table of arbitrary amounts of data that they're able to query and look up together. like global key value store that everybody can query into. Liquid inherited from Bitcoin kind of a a both a cultural and a technical opposition to that. I mean, the technical opposition is that this doesn't scale, right? If you've got nodes that are validating all of your transactions and all your blocks, you can't make them maintain this giant stateful database. Okay? Like even before this LLM boom, disk space was was kind of at a premium. Certainly, the fast random access discs that you need for this. So, this is a problem if you're building smart contracts, right? Because if you're trying to do a multi-party transaction where one party like publishes an offer and somebody needs to to take that offer or drop it or something, somehow you need a way to find out about this, right? And we don't have a global storage medium other than the the blockchain itself, which does not it's not indexed to do random data lookups. You can't access arbitrary blockchain data from within the script system, etc. We don't have a storage mechanism really. you got got to do this sort of commit reveal dance which is is difficult and importantly doesn't give you broadcast and the peer-to-p peer layer doesn't support this right so Bitcoin and therefore liquid right it's not Noster right it's not an arbitrary data passing around layer um Noster kind of appeared Noster isn't very helpful for this kind of problem because it turns out in a lot of cases you can just kind of free ride on Noster and and they're cool with it they want they want a bunch of noise uh to help obuscate whatever whatever the legitimate use case of Noster is it's just everybody passing around data that they can't see. It's is awesome. Uh so that's been helpful. So having no no bulletin board is is one difficulty. Uh and then the other one which the Ethereum world kind of embraced but we in the Bitcoin world cannot right is that if you have a uh an order matching mechanism where you publish an order and somebody grabs it, this is inherently frontrunnable by whoever is collecting and matching all of these orders. And in the Ethereum world, these are the block collectors or the block creators who take all of these orders, they put them together, they reorder them in whatever way uh gives them the maximum amount of fee or or may even allow them to be a middleman or whatever. And the result has been this incredible centralization of of block construction in the Ethereum world. Uh which has been a a great cautionary tale for us, right? And Liquid because Liquid is a federated chain. It's not a public blockchain with arbitrary miners. We could arguably embrace this as well, but we won't because we're not we don't have the constitution to do something that would be so antithetical if it was on Bitcoin, right? So, we've got to figure out how to solve this problem without creating these horrible incentives to create minor centralization and block construction centralization, which is kind of a a really difficult open problem. So then Scott shows up with like a company to run and a product to build, right? And I'm saying this is a really difficult open problem and it's like the future of like the social fabric of Bitcoin depends on us not doing it wrong. Uh so if you could hold off on making money until we solve it, right? Wouldn't that be cool? It's it's a tough ask, right? No, completely agree. We're not looking to solve a math problem in within sides. We're just trying to build like usable products so that people can actually access and um uh benefit from the structures within it. So what we did initially when we built sides swap was build effectively a bulletin board so that two people can find each other and they can construct an atomic swap between uh two parties which initially was effectively liquid Bitcoin and USDT and now lately we've seen quite a bit of volume in the deepix the Brazilian stable coin but but so two parties can effectively create an atomic swap between each other but the uh service that um sides swap offers is obviously the bulletin board and the messaging back and forth. But what we also do with segregated witness is remove the signatures so that one party will never receive a a signed transaction half from the other users so that they can effectively save those UTXOs and broadcast them at a later date, create the transaction if the price moves in their favor etc. Uh so that's a problem that sides swap has solved within the atomic swap aspect and we also use that as a matching engine to u when two people want to trade into shall we say a binary outcome contract which can be anything from a prediction market to anything else. uh when you have two parties uh we can affect that atomic swap into the contract between each other so that you don't have the resting orders uh that can be picked up these UTXOs. >> Welcome to predict the world is a market. Everything is a market. Every headline moves the line. Every moment is your market. Call the moves. Bet on your instinct, your prediction, your edge. Dual Bits predict where everything is a market. I don't really um I don't really understand how it works but under the hood but um unis swap and things like unis swap in shitcoin land they run like an AMM model or something instead of a regular order book and with sides swap you decided to go with just this open order book like you would think of it almost like linear like you see on on exchanges. Is there a reason you did that instead of going with like the unis swap model or >> Well, I think Andrew is much better placed, but I don't think it's even possible to do the AM model. >> Is it not? It's it's not impossible. It's harder, right? So, liquid is in in the UTXO model rather than the account model. So, a lot of the uh the sort of front running and reordering of transactions I was alluding to in Ethereum, you can't do in liquid because if you reorder transactions, then they no longer become valid, right? Right? There's kind of a fixed transaction graph. Every transaction takes inputs from previous transactions and so on. So if you implement an AMM on liquid, the way that you have to do it essentially is you've got some single UTXO out there that has the AMM code on it. And when somebody wants to deposit or withdraw from the AMM, they take that UTXO, they spend it. In order to spend that UTXO, they have to satisfy the rules of the AMM. And Simplicity would enforce that and so on. and then they put the remaining or or whatever the final balances are, those have to wind up back in the AMM contract. And then the next person does this. And so without some sort of coordination mechanism, if you have a hundred people or a thousand people trying to use this AMM at once within a block, what you'll have is a thousand different conflicting transactions and only one of them can get into the next block. This is bad for block propagation. For one thing, for the network, it's not so great. but also for users of the system. It means if you try to interact with AMM, you create a transaction, you publish it, well, guess you got a 0.1% chance that you're you're it will get into the next block. Otherwise, somebody is going to have to reconstruct this. So, in order to do an AMM style solution, which in Ethereum is is pretty easy to do because you've got kind of this like AMM contract code sitting there and it doesn't care what order thing. It's the the block creators problem. What order all of these hits to the the AMM happen in liquid and in the UTXO model in general. That order needs to be fixed in advance. So to solve that, there are solutions, but they're hard, right? And that they're harder than just using sides swap and they're harder than using some sort of bulletin board outside of the system. And uh and they they ultimately ground out on either having some sort of central coordinator who's like choosing an order and signing off on it or using complicated simplicity code to break the transaction graph in a way that allows it to be reorderable and then somehow teaching miners and or nodes how to do that reordering and then doing so in a way where they aren't incentivized to develop crazy uh um profit maximizing ways to do the reordering. and then you know all all the other like wallet and user and facing all the other infrastructure around that. So that's that's the difficult that's that's many of the difficulties in building an AMM on >> that actually makes sense. Um, so Scott, I mean, you keep saying prediction markets. Is your goal here to build poly market on liquid? A poly market competitor on liquid >> effectively. Yes. Right now we're just playing around at the edges at what's possible and trying to figure out the best way to uh yeah on board users in terms of the UX because they will need a sides swap wallet because no other wallet is able to interact with the the products that we're building yet. Uh but hopefully one day more wallets will be able to participate but for now um uh we've built the initial products which is you effectively can bet on the bitcoin price will it be higher or lower in the next x amount of time uh or um will the bitcoin price go up or down x amount of percent first. We're also looking at creating bit more like casino style games where you have provably fair betting. Uh um where you can place bets. But the nice thing is that we're looking so that anyone can be on the dealer side. Anyone can act as the house effectively. And the same thing with the prediction markets. So as long as you have a binary contract, you can have any outcome that an oracle can decide a yes or no outcome. And then as long as you trust the oracle, the contract is you know fairly straightforward setup. You just need to arrange all the market mechanics around it. Uh and so at this stage the contracts that we're looking at uh anyone who enters into them must hold the contract until maturity which is a limitation uh right now. Uh another limitation um is that once you enter into contract um the position that one party has taken cannot be traded with a third party so that uh you can replace whoever has taken the contract. So at least at this iteration stage anyone who enters into a contract needs to hold them to maturity. So an open-ended contract with uncertain end dates I think that wouldn't be wise today. But yeah baby steps one product at a Do you think those are all solvable or >> uh well again >> I mean the big one is I so as uh as a fan of poly market yeah um >> well I mean one of the coolest innovations of poly market compared to there's a bunch of reasons I think poly market is fascinating but one of the coolest innovations compared to a traditional sports book for instance is that you basically have liquidity before the term like I think that's like a key piece Right. So my question to you is do you think that piece is solvable? >> That piece is definitely solvable because it's effectively just someone who wants is willing to quote prices at some point in the order book and you can just like any other bots that hedge between exchanges. You could effectively hedge between prediction markets I suppose. U so I don't see any issue there. Um >> so one kind of interesting um bit of financial context right is that you can build a prediction market out of a tradable options market. You can also build a futures market out of tradable options. You can enable all sorts of hedging and speculation uh use cases. You can basically build anything in the financial world just by cobbling together enough options. So maybe a natural question is to say well why don't Scott like why don't you build an options market and then that will solve all these problems for you and the answer of well you're welcome to jump in if you want to try to answer that but I mean that the answer is that all the problems you've described you have to solve in order to do options and I think we were talking before this and one of the biggest ones is that in order to have positions that you can trade out of whether these are just uh prediction market like binary tokens or whether they're options or whatever, then you need a way for a wallet to understand what these tokens mean, right? If you you can there there's some layers of the technology stack, you can implement these as dumb tokens as like the equivalent of ERC20s in Ethereum or something. But in the end, if the user is holding an options token that represents the the right to say purchase Bitcoin at a given price at a given date, the wallet needs to know what that price and that date and whether it's a put or call, right? or if it's a betting token, it needs to know that this token represents the outcome of some event which is signed by such and such an oracle which will conclude at such and such a date or under such and such conditions and so on. And this leads into kind of this general question. Does everybody who implements these kind of markets, do they need to implement their own wallet? Do we have some general wallet language for describing these kind of things? Uh what what does the life cycle of one of these these tokens look like? And Ju just to interrupt. No, no, no. Since we don't have much time, but the main question is when you set these contracts up, do you have the contracts so that at the expiry that you pay out to like predetermined addresses or do you have that you pay out to whoever controls a claim token effectively? And if you create these tokens like how do you handle it in the wallet at the end where everyone needs to claim what happens with coins or tokens that never claim anything? Coins get stuck. There's so many other UX issues that arise because of it. So that's why we're just initially starting in the most easy points. >> Quick final thoughts, Scott. >> I mean, I love the work that they're doing with the liquid. Uh Bitcoin is finally getting the scripting capabilities so that we can actually build proper financial products just like all the other chains. I think the volume there has come from Bitcoin not having these capabilities. Finally, it's coming. like sides swap is yeah a company trying to help solve this if we're doing it correctly who knows but >> I love it you're doing great Scott final thoughts >> I I am believe it or not very excited and optimistic about all of this stuff there's uh these problems are are definitely solvable and the the ways that we're coming up with to solve them we didn't dive into the technicals of simplicity or simplicity HL or or what this like wallet protocol that I hinted at would would look and stuff, but the solutions that we're building for these things are big in general and and it's sometimes difficult to just like get a product out the door with them, but they enable a lot of stuff, a very broad range of things at a level of of trustlessness or a minimum of trust, however you want to frame it, um that really nothing else even comes close to. Um, and that that's that's super cool to me. >> I just want to real quick uh huge huge shout out and thanks to uh BTC, Inc. for how much resources they continue to put behind the open source stage and this whole hub area. I think um it's actually it's been really beautiful to watch over the last five six years. I mean it started in a sweaty nerd tent in 2021 in Miami and we've really come a long way. Huge round of applause for Andrew and Scott. Thank you guys. Every year this community comes together to celebrate, to debate, to build what comes next. And every year the stage gets bigger. Sound money center stage. So, where do you go to celebrate the next chapter in Bitcoin history? You come home. Nashville, July 2027.