Loky: Terminal UX for onchain intelligence

Overview

Loky is a terminal-style product for onchain intelligence, built specifically for traders in the Virtuals ecosystem, a category of web3 where the assets being traded are AI agents rather than protocols or memecoins. Researching and trading AI agents requires evaluating both price action and the actual utility of the agent and mindshare in the trading community, making the workflow more complex than standard token trading.

The product consolidates monitoring, analysis, risk review, and interpretation into a single terminal workflow, designed so each step hands off to the next without requiring a tool switch.

Loky terminal: six modules across monitoring, analysis, risk review, and assistant support.

Discovery

I led all discovery work independently. Trader interviews and signal analysis were my own. The module structure, terminal framing, and design principles were decisions I made directly from these findings.

Before designing anything, I interviewed experienced traders in the Virtuals ecosystem: participants with established followings who shape how the community interprets signals and makes decisions. I mapped their current tool stack (Birdeye, DEX scanners, Twitter and Telegram for mindshare, GoPlus for risk checks, AI assistants for interpretation), the actions they took at each stage, and specifically where the workflow broke down.

The clearest finding was that experienced traders had already built their own solution: custom automations covering alerts, signal routing, and execution. But those automations were brittle. In bearish or volatile conditions they became a liability, and the infrastructure cost of maintaining them was high. This was the key design insight: traders did not need more automation. They needed a terminal that was fast and clear enough to make manual decisions confidently, without the overhead of maintaining custom tooling.

The second finding was about trust. Signals in this ecosystem are frequently misleading, not because the data is wrong, but because external factors (macroeconomic shifts, coordinated community behaviour, scams) can make technically accurate signals point in the wrong direction. Traders had learned to distrust signals that did not explain their reasoning. Transparency of the why mattered more than accuracy of the what.

A third finding shaped the ambient monitoring requirement: crypto trading has no market open or close. Traders are distributed across time zones and active at all hours. The product needed to work at any moment of attention, not just during defined check-in windows.

Trader journey map: six stages from monitoring through execution, showing tools used, actions taken, sentiment arc, pain points, and workarounds at each stage.

The problem

The problem framing was developed by me based on discovery findings, and reviewed with the founding team before work began on module structure.

The challenge was not access to information. Traders had more data available to them than they could process. The challenge was making high-volume signals and metrics usable under ambient time pressure: fast enough to scan without losing meaning, connected enough to move from a change to its context and risk profile without switching tools, and transparent enough to be trusted when market conditions are unstable.

Discovery produced three gaps that defined the design brief: signals that arrived without context for why something moved, risk review that required leaving the scanning surface on every check, and AI-generated analysis that referenced data the trader could no longer see. Each gap is examined in the framing below.

Problem framing: three gaps, each showing observed behavior, where the workflow breaks down, and the root cause behind the breakdown.

From gaps to structure

The three gaps determined the module structure directly. Each gap produced a specific design decision, which shaped the surface built to address it.

Three of the six modules map directly to the three gaps. The remaining three support the overall terminal workflow: Onboarding gets traders into a configured state without friction; LQA Alpha is the repeat-check surface for comparing agents over time; Degen Dashboard provides depth on a single agent when a trader wants to move beyond the summary view. All six share the same interaction patterns, so the terminal reads as one product regardless of which surface the trader is using.

Design response: three research gaps, the design decision each produced, and the module that implements it. The fourth row shows the three workflow modules that complete the terminal.

Design principles

I defined these principles independently based on discovery and used them to make decisions across all six modules and the design system.

The gaps and the module structure above were shaped by four principles. Each principle maps directly to a finding from discovery and governed decisions across all six modules and the design system.

Module design

I designed all six modules end-to-end, including the concept for each surface, the information architecture, component design, and final specs. The color palette was defined by the client; everything else was my work.

Onboarding

Onboarding: connect wallet, confirm access, and subscribe to land in the terminal ready to use.

Onboarding had one job: get traders to a usable terminal state without friction. Each step has one clear action and an explicit next step. The flow ends at a configured terminal, not a blank screen.

Signals

Signals: filter and scan time-based alerts, then hand off any item to Ask Loky for interpretation.

Signals addresses the first gap: signals without meaning. Every card includes enough context to support a triage decision without opening a detail view. Filters narrow the feed quickly. Anything worth pursuing hands off directly to Ask Loky without leaving the surface.

LQA Alpha

LQA Alpha: compare agents via metrics using sort and filters, add to watchlist, and spot what moved at a glance.

LQA Alpha is the repeat-check surface. Traders return to it to compare agents and track movement over time. The layout is intentionally stable so it can be read quickly without relearning. Sort and filter controls match Signals exactly, so moving between them requires no adjustment.

Degen Dashboard

Degen Dashboard: review an agent in depth with a structured layout of headline metrics, charts, and supporting context.

Degen Dashboard provides the depth that LQA Alpha does not. It converts a single agent into a structured workspace: headline metrics at the top, charts and context below. Traders move from summary to detail without switching tools or losing the thread of what they were investigating.

Rug Scanner

Rug Scanner: triage risk by status and severity, filter the list, then open any row for deeper review.

Rug Scanner addresses the second gap: risk as a workflow detour. Status is legible at a glance, severity is interpretable without deep technical knowledge, and the module lives inside the same terminal so traders never break their scanning flow to run a check.

Ask Loky

Ask Loky: plain-language questions answered with structured analysis that ties back to the same objects in the terminal.

Ask Loky addresses the third gap: interpretation tools that produce answers disconnected from the data being reviewed. The assistant responds to what is visible in the terminal, explains the reasoning behind signals, and references specific objects the trader is already looking at. It is not a standalone chat interface. It is a follow-through layer built into the workflow.

Iteration

I ran usability sessions independently and used the findings to drive prioritized changes before finalizing the module specs.

After completing initial concepts for each module, I ran usability sessions with traders to pressure-test the designs before finalizing specs. Sessions focused on three specific areas: whether the scanning hierarchy in Signals and LQA Alpha was fast enough to use without training, whether the handoff between modules felt continuous or required reorientation, and whether the Ask Loky interface made its relationship to the terminal data clear.

The sessions produced two rounds of changes. The first round addressed information hierarchy: several cards were showing too much detail at the scan level, which slowed triage. The second round addressed the assistant interface: early versions of Ask Loky felt like a separate chat product rather than a terminal layer. The final design anchored responses to specific objects already visible in the terminal, which resolved the disconnect traders described in the research.

Design system

I built the design system in parallel with the modules rather than as a separate phase. Building it alongside real screens meant every component was stress-tested against actual layout constraints before being finalized.

With six modules shipping in a compressed timeline, UI drift was the main risk. If each module developed its own patterns for tables, filters, states, and actions, the terminal would feel like six separate products rather than one coherent system. The design system was the mechanism for preventing that.

The system was built in layers: foundations, navigation, input controls, data display, status patterns, and finally the assistant UI. Each layer was developed alongside the modules it served. The result was a system that constrained nothing and prevented drift across six surfaces shipping in parallel.

Foundations and layout rules

Foundations and layout rules: breakpoints, spacing and radius scale, type hierarchy, and the colour palette including semantic intent colours.

Navigation, controls, and data display

Navigation, input controls, and data display: sidebar and header variants, filter and button patterns, table structure, signal cards, and feed card hierarchy.

Status, feedback, and assistant UI

Status, feedback, and assistant UI: toast and tooltip patterns, empty state variants, and the full chat component set including prompt field states, message layouts, embedded charts, and quick prompts.

Reflection

The most consequential output of discovery was not a list of features. It was a reframe of the design question. The starting assumption was that the problem was information density. The research showed it was not. Traders were not overwhelmed by data. They were frustrated by data without context, workflows that required their own maintenance infrastructure, and tools that did not connect to each other. That reframe changed every structural decision that followed: which modules to build, how they connected, and what the terminal needed to do at each stage of the workflow.

Building the design system in parallel rather than after delivery also changed what it was capable of. Components defined through actual screen constraints were more durable than ones built speculatively. By the time the sixth module shipped, the system had been tested against six different layout contexts. The terminal felt like one product not because the system enforced a rulebook, but because the patterns had been earned through repeated use. The 65% first-session activation and 45% seven-day return rate reflected that: traders who reached the terminal understood it quickly, and came back.

In a high-density product, consistency is not a visual preference. It is what makes the system trustworthy under pressure.