Midl's L1.5 Pitch: Native Bitcoin, EVM Contracts, No Bridge Wait

Georgy Skryuchenkov counts the steps on his fingers. Locate a bridge. Wait three or four blocks if it is reliable, one block of 10 to 15 minutes if it is not. Set up a second wallet on the destination network. Claim the wrapped asset. Finally, at step four, do the thing you actually wanted to do, whether that is trading, lending, staking, or a SocialFi experiment. Then, when the time comes to cash back into real Bitcoin, run most of those steps again in reverse, sometimes waiting hours on the return bridge. "That's like seven steps," he says, "and I usually describe this in like 12 or 14 fingers, but I kept it short this time." That seven-step trip is the thing Midl, where Georgy works as DevRel, was built to delete.

Why Midl Avoids the L2 Label

Georgy has been in Web3 for six or seven years. He started as a junior smart contract developer after moving over from website work, drawn in by an interest in finance that, as he puts it, was "not limited by people." He says he has passed roughly 12 or 13 audits on contracts he has written, many of them shipped to production, before joining the R&D team that became Midl. The company has been building for over a year and a half and is close to mainnet.

The Midl team is careful about vocabulary. The project rarely calls itself an L2. Georgy frames Bitcoin's lack of programmability as both its greatest strength and its greatest weakness, and he reaches for a gold analogy to explain the design goal:

Store of values, they have a tendency to be wanted to be used in any other kind of ways by people. Usually, and we can see this with another greatest store of value in the world, basically gold, which is being utilized in finance in many, many ways, and you don't really have to basically hold like a gold coin in your hand to utilize this in your finance.

Midl's stated aim is to build as little as possible on top of Bitcoin and to pull the Bitcoin network as deeply as possible into an EVM-compatible environment. Every action on Midl uses a native Bitcoin wallet and native satoshis, with no separate claim step on a sidechain. That is why the team describes the project as L1.5 rather than L2.

One Step Instead of Seven

In Georgy's telling, the user flow on Midl collapses the bridge dance into a single connection. A user opens an app built on Midl, connects Xverse, Leather, UniSat, or a Ledger through a browser extension, and starts using it. Trading, lending with Bitcoin as collateral, and staking all happen at what he calls step number one. If a transaction returns an asset, including Runes or Ordinals, it lands back in the same Bitcoin wallet without an extra claim.

"This is all not even figured out for you by an application that you utilize, it's figured out by the infrastructure that we've built," Georgy says. He notes that the routing logic and the validator set are part of that infrastructure, and that handling a large validator set, rather than a small one, is something Midl considered crucial after watching problems on other Bitcoin L2s a few months earlier. He references the Tether comparison as a useful but imperfect mental model: a programmable representation of an asset that does not require physical hand-offs, except in Midl's case the trust is distributed across validators rather than a single issuer.

What Solidity Developers Actually Have to Change

For developers coming from Ethereum, Georgy says the contracts themselves usually do not need to change. Bitcoin is treated as the native gas token, the 0x0 address slot in EVM terms, so any contract that already handles native token transfers, balances, and send functions will work as written. The transition cost lives elsewhere.

Because Midl is not an L2, every Midl transaction still requires a Bitcoin transaction underneath, and Georgy is blunt about what that meant when the team started:

As a developer who transitioned from EVM environment into Bitcoin, I can tell you that this is like such a big pain in the ass. It's unspeakable.

That frustration produced the Midl JS packages, which are open source and meant to cover the basics: sending Bitcoin, iterating UTXOs, filtering UTXOs that are spendable in the current block, and the surrounding helpers an Ethereum developer would normally take for granted. Midl JS is built as forks of Wagmi, Hardhat, and in some cases Foundry, with the Bitcoin-specific behavior layered on top, so the APIs and interfaces stay close to what Solidity developers already use. The migration tax, according to feedback from teams that have already shipped on Midl, is mostly the conceptual jump in how Bitcoin wallets work compared to Ethereum, plus funding the wallet with Bitcoin instead of ETH.

Midl Vibe Code Hackathon Insights

A few months before recording, Midl ran what Georgy calls a Vibe Code hackathon, deliberately framed to see how far non-Bitcoin developers could get. He says participants pulled in smart contracts they found online, including non-developers among them, and still shipped working applications. Frontends were sometimes insecure, but the apps ran.

The submission count, by his recollection, sat around 60 to 80, which he describes as "alright, not bad, not great."; however, the unusual part was the success rate. More than 40 of the submissions actually worked, which he contrasts with his earlier hackathon judging experience, where most entries are easy to discard. One staking solution stood out to him for its financial design, though he is unsure if the developer continued the project after the event. He remembers asking his team whether they could expand the prize list because cutting working submissions felt unfair. He attributes part of that yield to the current pace of AI-assisted coding, and part to Midl feeling close enough to a normal EVM environment that participants "didn't really even understand, I think, that it was that much related to Bitcoin."