Earlier this week, I sat down with Matthew Black, the Chief Technology Officer of Atomic.Finance, to discuss Discreet Log Contracts (DLCs), a cutting-edge development in Bitcoin's often misunderstood smart contract ecosystem. Black unveils how DLCs are structured and set to revolutionize the world of financial agreements and transactions using the Bitcoin blockchain.
The discussion spotlights the specific infrastructure of Atomic.Finance, a pioneering platform specializing in Bitcoin-native financial services, and its overarching mission to redefine traditional finance within the Bitcoin ecosystem. Through a thorough examination of the underlying technology and the wider implications of Bitcoin-native financial services, Black explains how this paradigm shift may influence Bitcoin adoption, regulatory concerns, and the decentralization of financial services within the broader financial market.
A transcript of our conversation, lightly edited for length and clarity, follows below.
Mark Goodwin: Matthew, thank you so much for joining me. How many users roughly does Atomic.Finance currently have? And do you have an estimation on the number of bitcoin that's currently utilized in the system?
Matthew Black: It is still early days. We have 230 users, I believe. And just under 70 bitcoin locked at the moment. So we are still growing.
Goodwin: Have you guys encountered any regulatory issues while building these services? And is there a reason why you are based out of Toronto, in this current jurisdiction, versus being somewhere else?
Black: To be honest, we're in Canada because that’s where we're from. In general, there's certain laws and regulations that need to be followed around certain financial products, especially in certain jurisdictions. In our case, we take advantage of certain advantages that you get for building peer-to-peer applications in the current regulatory framework, especially, say, in the United States. And also, because of the jurisdiction that we're in, we're obviously not able to serve certain areas of the world, say sanctioned countries like Russia or Iran. We're not able to serve those countries, and that's unfortunate.
Obviously, I think the goal of anyone building sound finance for sound money is that you're able to serve the world. Bitcoin is money for the world. So you're able to serve the world but then we have to run into these very annoying jurisdictional problems. But the hope is one day we won't run into that. And other than that, we always just have to keep on top of the latest laws and regulations for these things. And it's always just a game; they create new laws, we have to keep up to date with them.
Goodwin: There's a cat and mouse game always with the regulatory regime. To be honest, I don't think it's going to slow down anytime soon. I think it's going to get more intense.
Let's get a little bit more into the tech here. I was reading your blog and there was an interesting comment made when describing previous iterations of smart contract based financial services. You guys made a comment that in other models, the entire contract appears on the blockchain for all the world to see, and that this information dense contract more quickly clogs the blockchain, leads to higher transaction fees, less privacy, and even enables Miner Extractable Value. Talk to me about how you address these risks within your current design.
Black: I think the biggest thing there is just the architecture design of DLCs versus Ethereum smart contracts. First of all, Ethereum smart contracts can be created by really any JavaScript developer and oftentimes there's this idea of creating a contract that can do anything that you possibly want to do and more. That results in you creating many different functions for all the possible things, whether it has to do with lending, whether it has to do with borrowing, whether it has to do with this or that. And all of that has to be spelled out and put transparently on the blockchain.
Ethereum is an account based blockchain. When you're using that published address, you must reuse that address every single time, right? And so the loss of privacy is enormous, versus looking at the architecture of something like DLCs. DLCs on-chain look very similar to a Lightning channel, actually. The funding transaction for a DLC looks identical to a dual-funded Lightning channel. And so what that results in is, first of all, that you can't tell if you are doing a Lightning channel or a DLC. And second of all, it's a 2-of-2 on-chain, and so the on-chain footprint is tiny, right? You're not really worried, to a certain extent, about fees, because the on-chain footprint is no different than opening a 2-of-2 and closing a multisig, which is really phenomenal. And the other thing too is no privacy is leaked about the actual contract itself.
Typically in Ethereum, you have these large kinds of honeypot contracts. And so say someone is using an AMM like Uniswap, someone can run a flash bot and come in and front run that transaction. That cannot occur in these types of contracts, right? Because it is that 2-of-2 multisig; it's the user and the market maker. And so those are the only two participants that were able to do anything related to that contract. So you don't run into this concern of MEV via a flash bot coming in and front running a particular transaction. And that's one of the things that DLCs really enable, I think the other thing with the current DLC paradigm is that you still have to go on-chain for every single position. There's also work being done on bringing this to Lightning as well, which I think is going to be the next iteration of the technology. You can open a channel with a market maker and do a bunch of trade and then go and close that channel, which makes this even more scalable for the long term.
Goodwin: Very interesting. You're basically incorporating an oracle of sorts in your HTLC state update, but otherwise it's structured exactly like a Lightning Channel. Is that the mechanism for how value goes back and forth in the channel, based on a price feed?
Black: Not quite. HTLCs themselves do not have these more advanced capabilities of DLCs, like being able to do bets, futures, and options contracts. However, the new upgrade, which I believe LND just pushed the other day, PTLCs, or point time locked contracts, do allow for these more advanced financial contracts to be created. In fact, you can do a DLC using a PTLC. Now the consideration for Lightning though, however, is that it doesn't really make sense to use routed lightning channels for these types of contracts.
So if you think of you and me, if we're going to enter into a bet, say like within a Lightning channel and say we have a bunch of peers between us — we've got you, Mark, we've got myself, and in-between us, we've got Bob and Alice. If we wanted to enter into that bet and say it's on the presidential election, in two years, if I wrote that DLC to you then Alex and Bob need to have their capital locked up for the next two years, right? Which is just insanity. That's never going to happen. So I think the way that this actually evolves is that you simply open up a channel to a market maker and then you go and do any trades that you want to them using DLCs and then you go and close it, maybe with one additional hop. But I think it's very unlikely that people are going to be willing to lock up capital all along these hops in a Lightning channel just to allow for people to do DLCs. And that's one of the drawbacks, obviously, of this system.
Goodwin: Interesting. In DLCs you utilize something called CETs, or Contract Execution Transactions. Can you explain how those work and what they are?
Black: I'll make a comparison to Lightning Network. So when you enter into a Lightning channel, typically what you do is you do state updates using HTLCs, right? If someone sends me a payment, then, I update my state in the background. That's really all a CET is, right? It just represents all the possible states of this DLC, of this 2-of-2 multisig. What you do when you first enter into a DLC is define what are all the possible outcomes that could be created. So the simple example: You're betting on the presidential election, Trump versus Biden. You have two CETs, right? Trump or Biden. Maybe you have a third one that's contested, right? These outcomes are all that a CET is. So there's two types of transactions that are created typically with a DLC. You have your CETs and you have your refund transaction. So the CETs represent all the possible outcomes, and the refund transaction is in the case that the oracle disappears, you still have a way to get your funds back. Even if that oracle disappears off the face of the earth.
So the simple example I gave was those CETs in which you have Trump, Biden, or contested, right? There's only three possible outcomes. But you can also do numerical-style DLCs, where say if you want to represent a curve, for example, a linear curve, or any type of financial contract that you can imagine. If you want to do a futures contract, you have a curve that's paid out based on the price, depending on what the price is. Maybe you're going long bitcoin, and the other party's going short. And then based on the outcome of what the price is of bitcoin, you have a payout. In our case, we're doing options. So say you have a long call contract, someone might come in and specify the payout, right? So this is the premium inside of the DLC. This is the possible payout, and then you have CETs that just represent every possible payout that can occur. So that's really all CET is; it's just what are the possible payouts.
Goodwin: Interesting. How are they actually constructed? It's not pre-signed, it's just pre-designated, correct? It's a spending condition, basically?
Black: It is actually pre-signed. You create signatures ahead of time. And what you do with these signatures, what's cool about them, is that it uses adapter signatures. The basic flow looks like this: In the process of the oracle creating their signature of a particular outcome, it basically decrypts and unlocks the signature of your counterparty, which then allows for you to sign the other side and then validate one of the CETs. So in the process of the oracle creating that signature, they validate one of the CETs, which then allows for you to go and take that transaction and broadcast that on-chain. This, of course, closes the DLC in the process.
Goodwin: That makes a lot of sense. You guys wrote on your blog that as long as the oracle correctly reports a result, the lone CET for that result is rendered valid. Talk to me about your confidence in the oracle systems present in your current design. How are they decided? Is it just a template that can input any Oracle system into it? Talk to me a little bit about that.
Black: That's a great question. So currently in our current system, we run the oracle. So there's us who run the oracle, and we've got a separate market maker that is the counterparty. Obviously there's opportunities here to distribute the risk even further. In terms of having a multi-oracle system. In the current system, obviously, there's a required trust in us, Atomic.Finance, to attest to the correct price. We actually run two types of oracles, to be fair. We run a price oracle, and that's for manual options contracts. And then we also run our strategies oracle, essentially. We have our covered call strategy, which is just an options trading strategy that's automated. They go and lock their funds into a DLC for a month at a time, and the oracle goes and attests to the P&L. These can be expanded to a multi-oracle setup in the future. You could have a two-of-three oracles, or a three-of-five.
One of the big considerations is the UI. As you add additional oracles into the system, in the current setup, it increases the amount of time that it actually takes to enter a DLC. Currently it takes around anywhere from 45 seconds to 2 minutes to enter a DLC on the Atomic Finance app. And the reason for that is because you have to create all of those off chain signatures, which obviously takes time. It doesn't actually take that much time to create the signatures, but it does when you consider that there's bandwidth considerations, right? If someone has a bad internet connection, they need to send that over to the market maker. The market maker needs to send those back. And then they need to back it up. We have a watchtower that backs it up just in case anything goes wrong. And so that's a really big consideration. And then if we're adding additional oracles on top of that it increases the amount of time it takes to sign even more.
Now, there's a couple of things that can solve this dramatically; number one is obviously CTV. We don't need to do any of this signature computation, in fact, all you need to calculate ahead of time, instead of the adapter signature, is the adapter point. This means about a 30 times improvement on the actual computation time related to DLCs. The other potential thing that could work is instead of adapter signatures, using BLS signatures. And Lloyd Furnier, he's a Bitcoin researcher. He's been doing a lot of work on this. With using BLS signatures instead, you could have the same setup that you have now, but have no slowdown in the amount of time that it takes to add multiple oracles.That might be really interesting, something that we look into down the line.
Goodwin: I definitely understand how the template aspect of CTV would help mitigate the need for constant party communications leading to a latency issue, but I'm not really familiar with BLS. Can you explain that to me?
Black: To be honest, I'm not an expert either. He was one that explained this to me, but I'll try to break it down. So basically with BLSs, the way that it improves this dramatically is that with these type of signatures, as long as there's a setup with the oracles ahead of time, say you had three large exchanges that were running oracles, as long as they compute a point together that they're going to attest to, it's like a Schnorr signature. You can aggregate signatures together, right? So with this you would aggregate the data points of the different exchanges together and, because you have that one point now, when you receive the signatures from those oracles, all you need to do is aggregate the signatures of those oracles together. At the end of it, you just have one signature that you utilize from the oracle rather than the alternative in the current adapter signature scheme where you would have three signatures that you then need to utilize and create different potential CETs. I think that the main advantage that you get is just that you're able to combine those signatures together.
Goodwin: Very interesting. You mentioned you guys have your own oracle, and you also mentioned the possibility of advancing distributed oracles, or weighted oracles, which I think is a good idea. Based on the current situation right now, or even going into this multi-oracle, multi-price feed scenario, are you concerned at all about any ability for market makers or people to manipulate these price feeds? I know there's a lot of issues with the more common smart contracts on Ethereum where a funky number from a funky feed can blow everything up. How do we mitigate that? Can these price metrics be manipulated by weighted users in the system?
Black: I think there's a really strange notion that exists within Ethereum that if we build decentralized oracles that will somehow solve the issue. And that just really looks like a bunch of anonymous oracles in which you don't know who's who. How do you know they're not all the same person? And so I'm actually of the opinion that it's not a decentralization metric. That's not what we're trying to run here. It's better to have a couple, like Liquid, right? You have a couple reputable functionaries that do a specific job and then they go and do that properly. In this case, I think it's a similar thing. If you have a couple of reputable folks that are running these price feeds that are all known, then it creates the right reputational environment for these price feeds to be correct.
So obviously, for our case, there's incentive for us to provide the right price feed to our users, because as soon as we provide an incorrect price feed, our users leave. And I think this is also a very important part of DLCs as well. When you think of a DLC people ask us, why don't you just use a multisig instead of a DLC? Why is it so much better? Imagine you enter into a multisig: You could have collusion between an arbiter, Alice or Bob. And it just affects that one contract. So you can steal from one user at a time. In this type of system, when you create that attestation, it's obvious to everyone and then as soon as that an oracle has been incorrect, you can stop using that oracle. I think the process of getting a proper price feed or proper oracle attestations is really just setting up either two-of-three or three-of-five oracles that are reputable and setting up the right incentives for them to continue providing these price feeds.
I think the other thing that's a bit wonky as well in Ethereum is that the oracles actually have to create a transaction in order to get that data on-chain to be utilized by the smart contracts. Whereas in Bitcoin DLCs, the oracle creates a signature completely off chain. And then the contract participants utilize that signature in order to close the contract. And so you never run into a situation like in Ethereum where gas fees were so high that the oracle price didn't update properly. You're never gonna run into that situation. It doesn't matter if you have Ordinals galore next week, you're still gonna be able to create that signature .
Goodwin: On your blog, you guys talk about covered calls, saying, “users always either end up with more Bitcoin or a Bitcoin stack that is worth more in U.S. dollars. There's never a risk of liquidation or total loss.” Explain to me how that's possible.
Black: An option is essentially like a coupon to be able to either buy bitcoin at a certain price or to be able to sell bitcoin at a certain price. What's the current price today, $27,000? So imagine I think that next week, bitcoin is going to be $35,000. And what I'll do is I'll tell my friend, “Hey, you know what? I'll pay you this coupon or this premium to be able to buy bitcoin at 30,000.” And he says, “Oh, you're crazy. bitcoin's going down next week. I'll take that bet. I'll take that premium. I'll receive income essentially from that premium because I think bitcoin is going to go down next week or even stay the same.” And that's the basics of a cover call: The person who's selling that call is the one that's earning that premium.
Now imagine in this scenario that bitcoin stays below the price, what happens? If I sold that call, I just earned that premium, right? And so I got more bitcoin. In the case that bitcoin goes up, and maybe it even goes all the way to $35,000, I still got that price appreciation from $27,000 to $30,000, plus I got the premium. Now I do end up with less Bitcoin at the end, but I end up with more in U.S. dollar terms. So that's the paradigm of cover calls and that's why it's just selling calls in general. It's a really interesting instrument because regardless of if bitcoin goes up or bitcoin goes down, you always end up with more bitcoin or more bitcoin in U.S. dollar terms. Now within our particular strategy, obviously lots of people don't want to end up with less bitcoin, right? And so we've built this particular strategy to be very conservative.
Goodwin: In Section 9 of your terms and services you mention that at your sole discretion, you may need to modify, suspend, disable temporarily or disable permanently some services, including possibly closing an open DLC. How is this possible within the system? And why is this feature important for you as a company?
Black: That's a good question. Actually in the current system, it's not possible for us to close any DLC of any user. They would have to do a mutual close with the market maker. It would only be possible to close it if we as the oracle provided an early attestation, right? So obviously that's always possible within the DLC, but I think it was basically just a legal clause to cover any potential eventuality. But the only ways that a DLC can be closed right now is either the user does a mutual close with the market maker, or we just don't create an attestation. In which case a refund occurs. And so I think the case for making an attestation early would be in the case that say our market maker isn't, for some reason, able to continue operating, and so we might just close it early to give people their funds back. And then, in the meantime, look for another market maker. I think that's the only possible case where that would ever occur.
Goodwin: And even in that setup, the user would still have to take the signature from your oracle to actually sign and close the transaction out themselves. So it's not like you guys could even force close a DLC at all. You can just provide the means to do it early, right?
Black: Exactly. Either the user can close it or the market maker can close it. And obviously I would assume that if the market maker is unable to continue, they would want to get their capital back. And so they might close it. But even if the market maker completely disappears, the user can always use the refund transaction. In the case that the market maker disappears, the user can still use our signature from the oracle to go close the DLC.
Goodwin: Makes sense. Do you even want to be the business running the oracle? Are you looking to get rid of that responsibility? Is that something you are aiming for, or is that considered mission critical to a solid infrastructure?
Black: I think we definitely, long term, want to move to a multi-oracle system where it's us plus some other parties, so it's not just on us. And we've even talked about the potential of working with some of the different DLC companies and actually creating a multi oracle system. Maybe we team up with 10101 or Lava, to all together create a multi-oracle system. Either that or just have exchanges that are actually running some type of oracle system. To be honest, I don't think we're tied to the idea of us just being the only oracle. In fact, I would rather that not be the case because then it's solely on us.
But at the same time, it's a business process of convincing other folks to go run that oracle and then the business considerations around the infrastructure costs of running an oracle. I think that's really the only thing, outside of the technical considerations, holding us back. Plus the discovery of who exactly can we get to run this right now? And can we trust them to run it effectively? Obviously our customers are on the line, and we want the best for our customers. I think it's best that we run the oracle right now, and then eventually it's a multi-oracle system in which we are one of the parties. Then eventually, we're just not running the oracles at all. That would be the perfect vision, I think.
Goodwin: Have you heard of UTXOracle? It's basically a UTXO set derived price feed or oracle. Do you see any merit to this idea? Do you see something like this maybe included in the future weighted oracle system? Or do you think it's just a cool idea that really has no economic utility?
Black: I think unfortunately it's the second, and I'll explain why. First of all, it is a really cool thing. And I love what they're doing. But at the same time, there's a couple considerations, especially for financial products. Options are very, very volatile in terms of their premiums and also very volatile in terms of volatility; that is what they thrive on. And so a ~10% range of accuracy is a really big consideration for us if we're utilizing that for an attestation. And then you have to consider that UTXOracle is software that's running alongside Bitcoin Core. It's not like there's some type of op code inside of Bitcoin Core that can go and utilize that price data. And even if there were, obviously this is very prone to manipulation, right? Because I think it was based on $50 or $100 increments, and they just looked at certain UTXOs.
So imagine someone starts putting in a bunch of UTXOs that are $53 or that are $47 or $45, right? And then that slowly modifies the price. So it's very manipulable. There's no obvious incentive to manipulate it, and I think it's a really cool tool, but maybe only useful as a validation check for an oracle. I'm making this attestation: Let me do a price check and validate against UTXOracle. And as long as it's in a certain range, then it makes sense. But in practical matters, I don't think it's too useful for DLC financial applications right now.
Goodwin: That's a good point. Perhaps you could use it as basically a sanity check within a double digit range. But a double digit range is very impractical for, 1%, 2%, 3% option. Acknowledging the difficulty of decentralizing price feeds, do you think it is even possible for a truly decentralized dollar instrument to exist?
Black: A purely decentralized dollar instrument? So I know 10101 Finance right now is building a StableSats dollar that uses DLCs and all they're doing is a 1x short on Lightning that allows for folks to get access to, essentially, StableSats using DLCs. But I wouldn't call that decentralized because obviously there's an oracle at the end of the day, right? There's an oracle that's providing some type of price feed for this to occur. A purely decentralized version would involve a type of price feed that wasn't easily manipulatable and that would actually be able to be utilized.
Say in an alternate universe, we had UTXOracle and somehow it was designed in a way where it wasn't easily manipulable. I don't know how you would do that. And maybe you had op codes that were based on it and then you could just grab the bitcoin price directly from the Bitcoin blockchain. Maybe you could have some type of dollar in that manner that would be decentralized. But I think the reality is that it's manipulable. And I think that we'll never get that opcode, ever. That doesn't make sense in Bitcoin land.
I think we can get close. I think we can get a distributed risk dollar, but I don't think we ever get a purely decentralized dollar because I think it's too easy for price to be manipulated. And I think that's the attack factor. There's another potential solution, too, for distributing oracle risk. I think the team at DLC Link is working on a FROST implementation for basically being able to aggregate Schnorr signatures together into one oracle. So you'd have 15 oracles and they all attest on the price and then that gets aggregated into one point. I haven't looked into the details of it. I don't know if that answers your philosophical question.
Goodwin: I think it answers it perfectly. Yeah, we'll see. It's going to get fun, and it's gonna get weird. Matthew, thank you so much. I learned a ton.
via bitcoinmagazine.com
