Hey reader, and welcome to the Midl Diaries or Midl Dev series (call it what you want)
This is the third chapter of our exciting book. Today, we’ll once again address the challenges of BTCFi and explain how we solved some of them with the vision we have for our product. You might come across some technical terms, but don’t worry; we ensured they are still readable for non-tech-savvy folks. Otherwise, feel free to use Google or ChatGPT for some of these.
This time, we will talk about how we transitioned from a simple signature encoding and decoding to executing a Solidity smart contract operation initiated with a Bitcoin transaction. So, let’s begin.
Second Proof of Concept: Running the Tx with a Node Triggered by a BTC Transaction
What’s important to understand here is that we always wanted to keep the activity on the Bitcoin L1 itself, but we also wanted to provide the computation power and ability to run complex smart contracts.
First, we had to change the classic EVM node structure to support a mapping of individual transaction batches with a Bitcoin transaction hash. That was the first step here. Essentially, it’s quite an easy thing: adding a new type of transaction, a “BTC” one, and adding a new field that accepts the Bitcoin transaction hash. That’s pretty much it. Simplicity is the core of every great idea. Creating a foundation for future virtual assets production based on validatorship consensus. So, we started with BTC as a native Bitcoin currency and having our users receive sats on their EVM account for the future tx execution.
Making This Tech Visible
But of course, running the transaction is not only about making sure that your virtual machine supports what you need but also communicating with it and interacting with it.
In our case, making sure that we could still use all the same tools we love in our usual developer lives was the most difficult or at least the most time-consuming part.
So, first of all, we forked the Ethers library, Viem library, and Hardhat in order to add a new type of transaction there and to deploy a native Bitcoin smart contract to add the new transaction field. This allowed us to sign and execute the Bitcoin transaction carrying the assets required for this elite transaction batch. We tested it with a simple “Hello World” contract, which accepts Bitcoin to store some data on a smart contract: an easy proof of concept. It took us a few months, of course, but we ultimately achieved it.
The next step was making the game a bit more difficult. We wanted to transition from supporting only native BTC usage to supporting a native Bitcoin standard. And after that, with asset standards like Runes, we had to start managing the UTXOs at the Midl TSS.
We had to constantly iterate our architecture to create a neat way of transitioning our virtual machines from the UTXOs into the account-based system. And that, folks, is a long story that we’ll go through in detail in future chapters.
Make sure to subscribe and all that stuff. And if you have any questions or requests you’d like us to talk about, feel free to drop them in the comment section.
Yours truly, Midl Dev Team
