There is a specific moment I keep thinking about. I was on a call with one of our institutional clients, a portfolio manager at a mid-sized hedge fund, and he was sharing his screen to show me how he tracked his DeFi positions. He had a spreadsheet. Rows of wallet addresses, transaction hashes he copied manually from Etherscan, prices pulled from CoinGecko every morning. This man managed hundreds of millions in traditional assets using Bloomberg Terminal. But for his growing DeFi allocation, he was doing data entry by hand.
That conversation stayed with me for weeks. It became the clearest brief I could have had for Merlin.
What Merlin was supposed to solve
When VALK decided to build Merlin as separate product in late 2021, the idea was simple on paper: a portfolio tracker and analytics dashboard for DeFi positions, targeted at institutional users. Aggregate data from protocols like Aave, Compound, and Maker, show performance in format that makes sense to finance professionals, help them understand what their on-chain capital is actually doing.
Simple on paper. Not simple in practice.
The deeper I went into research, the more I understood that the problem wasn’t just missing software. It was a trust and literacy gap between two worlds that have very different assumptions about what “good interface” looks like. DeFi dashboards are mostly built by crypto natives, for crypto natives. They assume you know what a liquidity pool is, that you are comfortable seeing your balance in ETH, that protocol names like Compound or Maker need no explanation. The interfaces reflect that, colorful, jargon-heavy, sometimes deliberately obscure in way that feels like badge of insider knowledge.
Traditional finance professionals, the people Merlin was aimed at, are not intimidated by complexity. They work with complex data every day. But they have completely different vocabulary, different trust signals, and much lower tolerance for ambiguity in tool that touches their capital.
The trust problem is a design problem
This took me a while to articulate clearly: institutional users do not trust interfaces that look “too crypto.”
I don’t mean they dislike the aesthetic in superficial way. The visual language of most DeFi products carries real signal for these users. Gradients, animated numbers, tokens displayed as colorful icons, purple everything, these are not neutral choices. For someone who has spent career looking at Bloomberg Terminal, Reuters Eikon, or even a well-built internal risk dashboard, these visual patterns communicate “retail,” “speculative,” “not serious.”
And in finance, if the tool doesn’t look serious, you don’t trust the numbers. If you don’t trust the numbers, you don’t use the tool.
So one of the earliest decisions I made for Merlin was to completely reject the aesthetic vocabulary of DeFi. Not to be boring, but to deliberately speak the visual language that institutional users already associate with reliability. Dense tables. Muted color palette. Data-first layout. Typography that feels closer to financial reporting than to web3 landing pages.
I kept thinking about Bloomberg Terminal as reference, not because I wanted to copy it, but because it represents something important: a tool designed so purely around the professional user’s needs that aesthetics became secondary. The people who use Bloomberg don’t care if it looks modern. They care if the data is right, if it loads fast, if they can find what they need without thinking.
Merlin was never going to be Bloomberg. We are startup, not forty-year institution. But that philosophy shaped every decision.
Denominating the world in USD, not ETH
This sounds small. It is not small.
When traditional finance professional looks at portfolio performance, they think in their base currency. For most of our institutional users, that is USD. They don’t want to know their yield is 0.003 ETH. They want to know it is $8.40, or $12.50, whatever the converted value is at current price.
Most DeFi dashboards show values in native tokens by default, sometimes with small USD equivalent in gray text underneath. That hierarchy made sense for crypto natives. It makes no sense for someone whose entire performance reporting framework is in fiat.
So in Merlin, USD was the primary display. Always. Native token amounts were secondary, available but not dominant. P&L was calculated and shown in USD. Yield was shown in USD. Every position across every protocol was normalized to one currency.
The implementation was harder than it sounds. We needed reliable price feeds, we needed to handle latency between on-chain data and price data, we needed to decide what to do at midnight UTC when daily P&L resets. All of this required very close work with the dev team, Anton and Alex in particular were deeply involved in making sure the data pipeline was solid before I could design any of the presentation layer.
This brings up something I thought about a lot during Merlin: in most products, if number is slightly wrong, the user is confused. In finance, if number is slightly wrong, someone calls their lawyer. The pressure on data accuracy was different from anything I had designed before, and it changed how I approached decisions. I became very conservative about showing anything I wasn’t sure the backend could reliably support.
Explaining impermanent loss without using that phrase
Impermanent loss is one of the most important concepts in DeFi for liquidity providers. It is also one of the worst-named concepts in any financial domain I have ever encountered.
For someone coming from traditional finance, “impermanent loss” sounds like contradiction. Losses are permanent. If you lose money, you lost money. The “impermanent” qualifier sounds like hand-waving, like someone invented word to make a risk sound less scary.
The reality is more nuanced, it describes the opportunity cost of providing liquidity versus simply holding the assets, but the naming creates immediate communication barrier. Institutional users I spoke to during research would visibly disengage when I used the phrase, like they detected a marketing trick.
So I stopped using it in the interface entirely.
Instead, Merlin showed “liquidity position P&L vs. holding equivalent assets.” Longer phrase, but one that lands correctly for finance professional. They understand P&L. They understand comparing a strategy against a benchmark. What you earned from providing liquidity versus what you would have earned just holding those same tokens, that framing is immediately legible in traditional finance terms.
The underlying math is the same. The communication is completely different.
This was one of the cases where learning the domain deeply paid off. I had spent weeks reading about how liquidity pools actually work, how AMM mechanics create this phenomenon, why it matters differently at different price ratios. I had to understand it myself before I could figure out how to explain it to someone else without reaching for industry jargon.
Aggregating three protocols into one view
When institutional user has positions across Aave, Compound, and Maker, they don’t want to check three dashboards. They don’t want to cross-reference their own spreadsheet. They want one view that tells them: this is your total deployed capital, this is your current yield across all positions, this is how it compares to last week.
The aggregation work was the core of Merlin’s value, and also the most technically difficult thing we did. Each protocol has different data structures, different event schemas, different ways of calculating interest accrual. Normalizing this into coherent single view required the dev team to do significant work before I even touched design.
From my side, the challenge was creating hierarchy that made sense across different protocol types. Aave and Compound are lending protocols, the mental model is: I deposited assets, I am earning yield, I may have borrowed against my collateral. Maker is more complex, a collateralized debt position with different risk parameters.
I created what I called internally a “protocol-agnostic position card.” Every position, regardless of where it lived, showed the same structure: asset, current value in USD, yield earned since entry, current APY, and a health metric if there was any liquidation risk involved. Protocol-specific details were available on expansion, but the top level was consistent.
This sounds obvious. But there were many debates about it. The argument against was that we were hiding protocol-specific nuance that sophisticated users needed. My argument was that sophisticated users can expand the detail, the default view should answer the most common question first, which is “how is my portfolio doing overall?”
Eventually we found the right balance. The collapsed view was clean and comparative, the expanded view was dense with data that analysts actually needed.
What I was designing with, and against
I spent a lot of time looking at competitive products during Merlin’s design phase. Zapper, DeBank, Zerion, the main DeFi portfolio trackers, and honestly well-designed for their audience. Zapper in particular has very good UX for the crypto-native user who wants to quickly see what’s happening with their positions.
But all of them were built around assumptions that don’t transfer to institutional users. The color palettes were saturated. The hierarchy put token balances ahead of USD values. Wallet addresses were displayed prominently rather than abstracted. The overall feel was consumer, not professional.
Looking at these made me more confident about going in the opposite direction.
The closest reference I found in traditional finance wasn’t a DeFi product at all, it was how some prime brokerage portals display multi-asset portfolio views. That was more useful to me than anything in web3.
Learning while designing
Something I want to be honest about: when Merlin started, I was learning DeFi myself.
I understood the conceptual layer, VALK’s tokenization work meant I had absorbed a lot about blockchain, smart contracts, asset representation. But the specific mechanics of DeFi protocols, liquidity pools, yield farming, the actual market dynamics, I was figuring this out in real time.
This created an interesting dynamic. I was designing product for traditional finance professionals who were also learning DeFi. In strange way, my position as intermediate learner, someone who understood finance logic but was still mapping it to DeFi mechanics, was actually useful. I could feel exactly where the communication broke down, where terminology stopped making sense, where you needed analogy to a traditional concept to make the on-chain version land.
I had to read. A lot. Protocol documentation, DeFi research posts, old finance textbooks that VALK’s CEO recommended. I kept a document where I translated DeFi concepts into traditional finance equivalents, which became kind of internal guide for copy and labeling decisions in Merlin.
There is something genuinely exciting about designing a product where the category itself is new enough that most conventions have not been established yet. At Spacecode, designing the fiftieth banking app, you were mostly making decisions within well-worn space. With Merlin, there was no established pattern for “DeFi portfolio tracker for institutional users.” We were making the patterns.
That pressure is uncomfortable. It is also the best kind of design work.
Where we landed
The version of Merlin we launched leaned conservative in almost every visual decision. Dark data tables, palette that avoided anything reading as “crypto colorful,” clear USD-first denomination, position cards with consistent structure regardless of protocol.
The response from institutional users was better than I expected. The piece of feedback I remember most clearly came from user who said it was “the first DeFi tool that doesn’t feel like I’m using something built by someone who wants me to feel confused.” I wrote that down and kept it.
We still had a lot to improve. Protocol coverage needed to expand. The reporting layer needed more depth for audit trail purposes. Some of the yield attribution calculations were simplifications of what we wanted to do eventually.
But the fundamental design decision, that the right approach was to design from the traditional finance user’s mental model inward, rather than from crypto conventions outward, I still think that was correct.
Most of the DeFi space designs for the believers. Merlin was trying to design for the skeptics, and it turned out the skeptics had a lot of capital they needed somewhere to put it.
Originally published on kargaev.me. Imported to blog.deeflect.com archive.