Web · 2026
Meridian
- Year
- 2026 – now
- Scope
- Web · Personal
- Role
- Product Designer & Full-stack Engineer
- Team
- Solo
- Stack
- Next.js, React, TypeScript, Tailwind CSS
- Status
- Ongoing
- Links
A wallet-consensus agent for opening, rebalancing, and closing concentrated liquidity positions on Robinhood Chain.
An autonomous liquidity-provisioning system that turns weighted activity from tracked wallets into auditable entry, rebalance, and exit decisions for Uniswap V3 pools on Robinhood Chain, with a mock-first operator dashboard and strict safety controls.
Concentrated liquidity in fast-moving token pools creates a narrow opportunity: fees are strongest while volume is rising and TVL is still thin, but entering late or leaving late can turn the position into a concentrated bag of a falling token. Manual monitoring cannot consistently combine Telegram signals, wallet activity, pool state, range status, and exit timing around the clock.
Read moreShow less
Meridian turns the active commitments of operator-selected wallets into one consensus score. Each wallet has a manual weight, time decay, a size multiplier, and a cluster cap so several wallets funded by one actor cannot masquerade as independent confirmation. Crossing the entry threshold opens a position; a price move outside the active range triggers a rebalance only while consensus remains healthy; a score below the floor closes the position. Every decision records its score, contributors, selected range, and reason.
The current implementation is a mock-first Next.js operator dashboard. Overview, Wallets, and Pools are implemented with realistic fixtures, live event simulation, loading and failure states, weight-impact previews, contributor inspection, and write guards when the daemon is unavailable. A single DataSource contract isolates every component from its source, so the mock adapter can later be replaced by the server-side bridge without rewriting the interface. The remaining execution daemon and bridge integration are still in progress.
The target daemon uses LP Agent data as the primary commitment feed and Robinhood RPC as its fallback and source of truth for funds under management. It executes Uniswap V3 positions through viem, stores event history in PostgreSQL, distributes live updates through Redis and SSE, supports dry-run before real capital, and keeps a persistent multi-level kill switch. Net PnL, not gross fees, is the primary performance measure.
Brief
Problem
The best fee window in a new concentrated-liquidity pool can last only minutes, while a safe decision requires combining signals, independent wallet conviction, live on-chain pool state, range health, and exit timing. A manual operator cannot watch all of those continuously, and following raw wallet counts can mistake one actor split across several addresses for genuine consensus.
Solution
A single auditable decision loop scores weighted wallet commitments with time decay, size confidence, and cluster caps, then uses fixed rules to open, rebalance, or close a Uniswap V3 position. RPC verifies every value involving managed funds, dry-run proves the path before capital is enabled, and the dashboard exposes the score, contributors, PnL decomposition, stale-data state, and kill switch.
My role
- 01
Defined the product rules, system boundaries, data model, bridge contract, milestones, and acceptance criteria in the Meridian v2 PRD
- 02
Designed the consensus model with wallet weights, time decay, size confidence, hysteresis, cluster caps, and a cold-start ceiling
- 03
Built the mock-first Next.js dashboard foundation, design system, navigation shell, operator overview, wallet registry, and pool-monitoring surfaces
- 04
Created one typed DataSource interface for mock and bridge adapters so UI components never depend on fixture files or daemon transport
- 05
Added realistic fixtures and scenarios for happy, empty, cold-start, halted, and daemon-down states, plus simulated live events
- 06
Specified safety controls for dry-run, multi-level kill switch, daily limits, stale data, write guards, dedicated hot-wallet isolation, and auditable decisions
- 07
Wrote contract and unit tests for fixture validity, data-source behavior, formatting, accessibility contrast, and mock import boundaries
Features
- 01
Operator overview with equity, net PnL, open-position, loss-limit, fee, daemon, and equity-curve states
- 02
Wallet registry with add, edit, enable, remove, CSV import, inline weighting, impact preview, and weight suggestions
- 03
Pool monitoring with consensus score, threshold state, tier filters, tracked-wallet flow, contributor breakdown, and manual evaluation
- 04
Cluster-coverage warning and cold-start score cap to reduce false consensus from related or unclassified wallets
- 05
Swappable mock and bridge data sources behind one typed interface, with TanStack Query caching and live cache updates
- 06
Happy, empty, cold-start, halted, and daemon-down scenarios for deterministic development and review
- 07
Write actions disabled with a visible reason when daemon health is unavailable, while stale read data remains visible
- 08
Multi-level kill-switch and dry-run controls designed around explicit confirmation and an audit trail
- 09
Net PnL decomposition that keeps claimed fees, unclaimed fees, impermanent loss, and gas distinct
Architecture
The implemented dashboard is a Next.js App Router application whose pages depend only on a runtime-validated DataSource contract. A fixture-backed mock adapter supports deterministic scenarios and simulated live events; a server-side bridge adapter is the planned swap point for the daemon. TanStack Query owns server-state caching, live events update that cache directly, and Zustand holds local UI state. The target daemon follows inward dependencies: pure consensus, range, position, sizing, limit, and PnL domains sit behind ports; LP Agent and Robinhood RPC commitment readers, Uniswap V3 execution, PostgreSQL, Redis, Telegram, and the dashboard bridge remain adapters. SSE carries live state to the dashboard, while all write commands pass through one allowlisted tool endpoint.
- Front end
- Next.js, React, TypeScript, Tailwind CSS, Radix UI, TanStack Query, Recharts, Zustand
- Back end
- Node.js, Zod, viem
- Data
- PostgreSQL, Drizzle ORM, Redis
- Infrastructure
- PM2, systemd
- Tools
- Vitest, ESLint, Excalidraw
- Integrations
- Robinhood Chain RPC, Uniswap V3, LP Agent API, Telegram Bot API
Challenges
- 01
Problem
Counting wallets directly lets one actor split capital across several addresses and appear to be independent conviction, especially before funding relationships have been classified.
Solution
Grouped related wallets under a shared cluster cap, tracked classification coverage explicitly, and limited the total score during cold start until enough active wallets had been classified.
- 02
Problem
The dashboard had to be built before the execution daemon without letting mock fixture shapes become an accidental backend contract or leak into UI components.
Solution
Defined runtime-validated schemas and one DataSource interface first, implemented mock and bridge adapters behind it, and added tests that reject direct mock imports outside the adapter layer.
- 03
Problem
An autonomous system managing funds cannot turn a daemon outage into a blank screen, silently accept stale state, or leave write actions available when health is unknown.
Solution
Kept the last readable state on screen with a clear stale-data banner, disabled writes with an explanatory tooltip, and modelled daemon-down, halted, and cold-start as first-class test scenarios.
Lessons
- 01
A consensus score is useful only when every contribution, cap, threshold, and state change can be reconstructed later.
- 02
Build the data boundary before the backend: a strict adapter contract lets the interface mature on realistic fixtures without coupling it to mocks.
- 03
Failure and uncertainty are product states, not edge cases; stale data, partial classification, and disabled writes need deliberate UI treatment.
- 04
For an automated liquidity system, net PnL after impermanent loss and gas matters more than gross fees.