1/7
“Study the dev diaries before you ape into BTCFi.”

@midl_xyz has been documenting their journey step by step, and we’re here to take a closer look at it.

Because they’re patching the gaps that make building on Bitcoin so frustrating. https://t.co/lbugsbKa9j

2/7
Their first step was simple: run a dApp using only sats.

But even that turned into weeks of cryptographic experiments.

They managed to get a Solidity smart contract to execute a transaction triggered by a Bitcoin wallet using BIP322 signatures, and that was their first proof of concept.

3/7
The next step was to make that execution visible and repeatable.

They modified the core EVM tooling to understand Bitcoin transactions, including Viem, Ethers, and Hardhat. They added a new tx type with a BTC hash trigger.

It worked, and they managed to launch a contract where Bitcoin initiated logic on an EVM VM.

That’s why Midl started building their own libraries. This is how midl.js was born with open-source, focused and shaped by real-world usage.

6/7
We’re glad they didn’t stop at making Runes usable and connecting them to ERC-20 logic. They’re building actual infrastructure for native dApps.

Midl now enables direct swaps between Runes tokens, powered by Bitcoin transactions and settled with Solidity.

7/7
We believe Midl isn’t just a project choosing the hard path. It’s something the Bitcoin community genuinely needs. Finally, someone is fixing what others ignored for years.

This laid the foundation for BTCFi where devs can work at the pace and with the clarity they’re used to on Ethereum.

@midl_xyz https://t.co/e1DmqiTOxd

4/7
At that point, it was time to go beyond sats.

They started experimenting with Bitcoin-native token standards. The most promising? Runes.

Runes were still early and rough, but they offered just enough structure to build something composable and light.

5/7
As they put it: DevEx was terrible.

It takes 3–5 days just to get a basic Runes PoC working with few tools and little guidance available.