Ship something rough and fix it later is good advice, until your product holds other people's money from the start.
In February 2026 we launched Liquidium's Cross-chain Lending protocol. It took 21 months from the first ticket to public launch. I've already written about how the tech works here: Cross-chain Loans: Utilising ICP's Chain Abstraction. This one is about how we worked around not being able to ship a rough draft.
Starting a second product while the first one was still growing
When we started planning our Cross-chain product, our existing peer-to-peer protocol was growing fast and bringing in real revenue. It has since done 4.4k BTC in total volume across 128k loans, paying out over $5M in interest to lenders.
You can see the shape of it. A steep ramp through the Ordinals run, a second Runes driven peak through 2024, then a decline through 2025 into 2026. We still maintain it and it still gets used, but it's a speculative market, and that was always the risk. We didn't want the entire company hedged on one collateral type.
So the question we asked wasn't "what do we do now that this is slowing down". It was "what does the end product actually look like". Our thesis has always been to be the biggest lending protocol for Bitcoin. Bitcoin is the largest asset in the market and it has been almost entirely excluded from lending. That was the target.
The argument against it was runway. This isn't something you ideate quickly and get out the door, and Aave already dominates on Ethereum and could move toward Bitcoin at any point.
But the constraint that actually shaped many decisions after that was narrower. A lending protocol has no useful MVP in the traditional sense. There is no version that half works. It either holds the money correctly on day one or it doesn't, and if it doesn't you don't get a second attempt after losing users trust.
Testing the platform in production before we bet on it
An MVP normally de-risks your tech choice for you. You build the rough thing, and if the platform can't do what it claimed, you find out cheaply.
We didn't have that option, and this was the biggest decision in the project. There were two realistic platforms, ICP and NEAR. NEAR had genuine advantages, particularly the swap liquidity on their chain, which matters when you're thinking about liquidations. ICP's chain abstraction was further along.
What settled it was something we'd already shipped. On the P2P app a borrower had to wait for the lender to countersign before a loan could start, so we built a helper on ICP that countersigned for them and let loans start immediately. A quality of life feature, running in production, on the platform we were evaluating.
Comparison documents tell you what a platform claims. Building on it tells you the things that never make it into documentation. How good the tooling actually is, how quickly you get an answer when you hit something undocumented. Dfinity and the ICP community were excellent on all of that, and we wouldn't have known it from research alone.
If you have a platform decision coming and no way to prototype the real product, ship the smallest genuinely useful thing you can on the candidate instead.
Four months before anyone wrote code
The application project opened on 30 June 2024. The core protocol project didn't open until 25 October 2024.
That gap is the planning phase. Architectural specs, user flows, comparison docs between existing protocols, analysis of how their mechanics actually work. We based the core lending logic heavily on Aave's proven model, so we weren't reinventing the wheel there. The innovation sits on top, bringing native assets from their own chains and letting them be combined in one market.
We built this as two separate projects with two leads. The protocol running entirely on ICP, and the frontend as an accessibility layer on top. If Liquidium disappeared tomorrow, the protocol keeps running. But that meant two repos that had to integrate cleanly 18 months later, with no shared running product to test against in between. Weekly standups helped. What actually kept both sides pointed at the same thing was those docs staying the source of truth for the whole build.
Faking an MVP with a demo
Before the rest of the engineering team was free, I built the entire UI as a mock. We initially ran a survey that got over 100 responses, and about 20 of those people got on calls and used it in front of us.
Its a great opportunity to watch someone use an interface for the first time. You can see what it isn't landing, and no amount of internal deliberation gives you that.
The mock didn't get thrown away once development started. It stayed the thing we put in front of people while the protocol was being built, and mocking functionality let us keep testing flows that didn't exist yet. Feedback came in continuously across the whole build instead of arriving all at once at launch. The UX decisions were settled while they were still cheap to change.
We refactored instead of patching
In May 2025 we had a booth at Bitcoin Las Vegas and announced the product publicly for the first time, targeting Q4 2025. But we ended up missing that target.
Our audit came back with few high severity findings and a lot of small ones. Every one of them could have been patched individually, but we decided to take the longer route of refactoring the architecture.
Patching fixes the problems you know about, but the architecture reduces the probability of the ones you don't. No audit finds everything, and when a lot of small issues surface in the same places that's more of an indication about the shape of your system. Without a launch and iterate option, reducing the unknown class of bugs is worth more than closing the known ones.
Most of the findings were rooted in the same thing. ICP isn't atomic the way Ethereum is, so write ahead logs, rollbacks and handling calls that never complete are all your responsibility. We had that logic sitting inside the core pool, which meant every path through the system carried some of the risk. Separating the core accounting from the layer that touches user funds means anything that doesn't fully complete stays on the outside, and the surface area where something can go wrong gets a lot smaller.
This pushed our launch to 24 February 2026. The Trail of Bits review closed out at 25 findings, all resolved.
Going live
We launched with BTC and USDT at around $100k borrowed, then added USDC at the end of May, ICP mid June and ETH in early July.
We're now at roughly $1.3M borrowed against $4.7M supplied, growing around 30% week over week and in triple digits month over month. ICP picked up fast after we added it, the same pattern as Bitcoin and the whole point of the protocol. A chain with real capital sitting on it and no proper lending market of its own, now connected to the same liquidity as everything else.
Two things helped. Simple Loans, shipped 22 May, lowered the barrier for a first time user by collapsing borrowing into a single step. Request the amount, deposit your collateral, receive the funds. It's become a good gateway into the advanced flow, where positions tend to stay open far longer. And our public SDK now lets third parties integrate borrowing and lending directly, including one of the major ICP wallets.
Keep in mind, this growth has been happening in a bear market.
What I got wrong
I tend to be overly optimistic and overestimated how fast this would scale. Capital follows capital, and $100k borrowed and $1M borrowed are completely different trust signals to someone deciding whether to supply. It just takes a bit longer for the flywheel to come into play.
We also didn't fully set the product up for analytics from day one, and your earliest users are the ones you don't want to misread. In our case it was a bit tricky to define metrics, for example an "active user" is close to meaningless in lending, where someone who supplies capital and never opens the site again for a year is more genuinely active than a daily visitor. We have been ramping things up recently using on-chain analytics and automated reporting to trace where liquidity comes from and what people use it for. It should have been there from the start.
Everyone jokes that you should double your engineering estimates. It has some truth, but times are changing with the speed we are able to ship due to AI, and our development flows have improved considerably since starting this project.