Choosing Native Bitcoin Standard Token. Why Runes?
Hey reader and welcome back to Midl Dev Diaries or MIDL Dev Series, call it what you want.
This is the 4th chapter of our exciting book and today we’ll once again address the challenges of BTCFi and explain how we solved them, and share our vision about the BTCFi projects and protocols overall.
You might come across some technical terms, but don’t worry, we ensured that they are still readable for non-tech-savvy people. Otherwise feel free to use Google or Chat GPT to have the most complex ones explained!
This time we are going to talk about native Bitcoin standard tokens, and, spoilering the article, specifically talk about Runes.
From Bitcoin Transactions to Runes
As explained in the last chapter, we successfully executed a Bitcoin-triggered Solidity transaction and we were then running a very limited example of proof of concept of a Solidity dapp where the contract accepts just native Bitcoin
Next step obviously is to connect ERC-20 tokens in there.This step requires not only writing an ERC-20 token contract, of course, but also understanding what we would match this ERC-20 on the Bitcoin side with. We obviously were driven toward the meta protocols, and selected the one which stands out in our opinion, Runes.
Runes was an easy option for us to choose over a year ago, and while the standard was and is still very young, it has a lot of room to improve.
We believed in Runes a year ago and we still believe it is the one to use out there, at least at the moment. We’re not limiting ourselves to Runes: we can utilize other native Bitcoin standards as well, but this is what we are starting with.
That being said, it still is very, very difficult to use Runes.. We saw developers start using Runes and inscriptions, and even when familiar with the BTC environment, it usually takes 3–5 days initially to play around and get their head around the protocol. By that time, they usually are able to complete some very limited proof of concept examples. It’s still very poor for the time spent, and usually carries a great technical debt coming along with it.
I can already tell you that this was the breaking moment for us.We then decided to invest time into building something to bridge that gap, and started working on our open-source libraries, as the amount of available open-source resources in the bitcoin space was really poor, especially for Runes. So this is how we decided to have MIDL.JS created and we started working with Runes at that point.
Runes are Great. But still Have Space to Grow
Runes essentially allowed us to focus on using only OP_Returns.
Author’s note: OP_RETURN is a script opcode used in Bitcoin and other UTXO-based blockchains that allows you to embed arbitrary data into a transaction: think of it as a way to write small pieces of permanent information into a Bitcoin transaction.
It’s lightweight enough to fit in two Runes transfers or actually two Runes edicts in the transaction, which is very important for cases like depositing liquidity into an automated market, making pools or scheduling more transactions in a single batch of transactions.
So Runes essentially have everything that we need. It has a more or less compatible way of holding names and symbols.
The only thing which is missing right now within the Runes design is support for the stablecoins case. Right now it is still difficult to achieve this with Runes, so we tried with Ordinals as well, but with the same limitations.
And this is also my shout out to Casey and Raph on making us reconsider why stablecoins support is essential and for the introduction of proper authorized burn, authorized burning functions and authorized mint functions.
We are not only seeking to support stablecoins here. Stablecoins is just one of the primary examples on why the utility is required.
Swap Proof and Development Speed Challenges
As soon as that is done, I believe that the Runes are going to be the standard for the whole Bitcoin ecosystem to go through.
As soon as we figured out how to use Runes and how to utilize them and connect them up with an ERC-20 protocol on the computational environment, we were able to execute swaps: exact token-for-token transactions where we swapped Runes with one another.
This was the completion of our proof of concept developments. After that, we started improving the products in an iterative way, working on the stability and usability.
We noticed that once again, the greatest challenge is not to provide the proof of concept, but to do it quickly.
For us, it took about 6 months to deliver, which is of course very slow and quite frustrating. And we knew we could do better.
We’re sure Odin.fun folks get this: they spent way too much time on creating their Proof of Concept there as well. And no dApp should stress such things. Development should be easy.
And we want to make sure that it becomes much quicker to deliver dApps like the one Odin.Fun did, but with an increased security, improved DevEx and without being an isolated dApp, but instead, being part of the whole DeFi ecosystem emerging with the Bitcoin L1
We have to make sure that deployment of protocols on Bitcoin shouldn’t take more time than it takes on the Ethereum side, and it should be a nice and easy experience for the devs and builders.
And this is the topic we’ll come back to in our next chapter.
