I started this project about 7 months ago. It is open source, FREE to use / test. If you want to support my work, there is a BUY UTTT button and also a donate button on the header you can use.
https://github.com/eyemaginative/utt-unified-trading-terminalUTT — Unified Trading Terminal: local-first trading, wallet tracking, DEX routing, tax/basis tooling, and multi-venue crypto operationsProject: UTT — Unified Trading Terminal
Token / project asset: UTTT
Status: Experimental open-source desktop/local trading terminal
Current focus: Local-first exchange aggregation, self-custody visibility, DEX routing, wallet-history ingestion, tax/basis tooling, and practical crypto operations.
Important note up frontUTT is not being presented as a security, investment contract, managed fund, exchange, custody provider, or financial adviser. It is a local-first software project intended to help users organize, view, and interact with their own exchange accounts, wallets, market data, DEX routes, deposits, withdrawals, orders, and cost-basis information. Nothing here is financial advice. The software is experimental and should be treated like power-user tooling: test carefully, use small amounts first, keep your own backups, and understand what every connected API key or wallet signature can do.
What is UTT?UTT stands for
Unified Trading Terminal. The goal is to build a local-first crypto command center that brings together the pieces most crypto users currently have scattered across many different apps:
- centralized exchange balances
- centralized exchange orders
- on-chain wallet balances
- DEX swaps
- market cap / volume reference data
- token registry metadata
- deposits and withdrawals
- basis lots and FIFO tax calculations
- self-custody wallet snapshots
- project/token management tooling
- local API-key storage and database backups
Instead of forcing the user to constantly jump between Coinbase, Kraken, Gemini, Robinhood, Solana wallets, Polkadot/Hydration tools, explorers, spreadsheets, tax trackers, and DEX interfaces, UTT is designed to become one local terminal where those workflows can be gradually unified.
It is built as a local application with a FastAPI backend, a React/Vite frontend, and a SQLite database. The basic philosophy is simple:
Your trading terminal should belong to you. Your data should be local. Your keys should not be hard-coded into source files. Your wallets and venues should be visible in one place. Your activity should be organized into a ledger you can understand.
What does UTT currently do?UTT has grown from a basic trading terminal into a broader crypto operations dashboard. The current published baseline includes the following major systems.
1. Multi-venue exchange supportUTT is designed to connect to multiple trading venues and normalize their data into a common interface. Current work has included support paths for:
- Coinbase
- Gemini
- Kraken
- Robinhood Crypto
- Crypto.com Exchange
- Dex-Trade
The purpose is not merely to display a balance from one exchange. The goal is to ingest and compare balances, order data, fills, fees, native venue order IDs, local routed orders, and terminal/open order states across multiple venues.
The terminal has an
All Orders table that reflects local orders, venue-native orders, and DEX swap rows where available. It also includes a viewed/confirmed workflow so new or unreviewed activity can be surfaced and then marked as seen.
2. Local-first API key managementUTT has been moving away from static environment-file secrets and toward a local profile/API-key vault model. The idea is that API keys should be managed through the local app profile rather than committed into code or scattered across scripts.
The project uses local authentication, profile management, 2FA support, and DB-backed API-key storage. Sensitive values are intended to stay local, and the publishable repo is kept free of private keys, live .env files, databases, and runtime secrets.
3. Portfolio balance aggregationUTT can show a total portfolio value across venues. The latest baseline improved this so that the AppHeader portfolio total can include cached wallet-address and self-custody balance snapshots, not only CEX balances.
That matters because a realistic crypto portfolio is not only exchange balances. It may include:
- CEX balances
- Solana wallet balances
- Hydration / Polkadot ecosystem wallet balances
- BTC / DOGE / DOT self-custody addresses
- custom project wallets
The goal is for the top-level terminal balance to represent all known tracked holdings, even if the user has not manually opened a specific balances window during that session.
4. Self-custody wallet-address trackingUTT includes a wallet-address system for tracking on-chain addresses. These are separate from centralized exchange balances.
Wallet addresses can be registered with fields such as:
- asset
- network
- address
- label
- wallet grouping
- owner scope
The backend can store wallet-address balance snapshots and transaction rows. This creates the foundation for local wallet history, deposit detection, withdrawal detection, and transfer-linking between wallets or venues.
5. Solana / Jupiter DEX integrationUTT includes Solana DEX wiring using Jupiter for swap workflows. The terminal distinguishes DEX flows from normal CEX limit-order flows so that selecting a Solana DEX venue does not break or interfere with centralized-exchange behavior.
The Solana/Jupiter work includes:
- wallet-provider detection and connection paths
- swap transaction building
- sign/send flow through the user's wallet
- Jupiter quote/orderbook-like sampling paths
- swap-order recording into a local swap_orders table
- reflection of DEX swaps into the All Orders table
- better handling of native SOL legs, token/SOL pairs, and swap-like transaction classification
The philosophy is opt-in DEX support: DEX functionality should activate only when a DEX venue is selected and should not gate or break existing CEX workflows.
6. Polkadot / Hydration workUTT has an active Polkadot / Hydration integration track. The current Hydration work includes:
- Hydration RPC configuration through Dwellir or equivalent RPC providers
- Profile/API-key support for Hydration RPC keys
- Token Registry metadata for Hydration assets
- Hydration balance lookup paths
- Hydration asset resolution
- manual route / pool fallback support for custom routes such as UTTT-HDX
- protected SDK quote behavior to avoid hammering RPC quotas
- controlled price cache experiments
A major current goal is to add full Hydration wallet-history ingestion: deposits, withdrawals, basis queue handling, and bridge transfer records. This is being approached carefully because address history is not the same thing as balance state, and it should not rely on heavy SDK quote calls or uncontrolled RPC polling.
7. Token RegistryUTT includes a Token Registry window and backend model. The registry stores metadata such as:
- chain
- venue override
- symbol
- address / mint / contract / asset ID
- decimals
- label
- external price source
- external price ID
This is important because token metadata is different across networks:
- Solana uses mint addresses
- EVM chains use contract addresses
- Hydration uses asset IDs, with HDX as native
- global market data providers use their own coin IDs
The registry helps UTT avoid hard-coding everything in backend files. It also lets market data lookups use user-managed metadata first.
8. Market Cap and Volume tooltabsThe latest completed tranche added AppHeader tooltabs for:
These windows use a backend market_metrics service rather than calling market APIs directly from the frontend. The backend can cache results, use Token Registry external price IDs, fall back to known mappings, and auto-resolve selected assets through CoinGecko symbol search when appropriate.
Important behavior:
- The AppHeader chip fetches the selected UI asset only.
- The Market Cap / Volume windows can fetch DB-owned or tracked assets.
- The backend caches CoinGecko rows and can serve stale data when rate-limited.
- The Token Registry is now preferred over hardcoded symbol maps.
- Assets like MATH can be resolved automatically when selected if CoinGecko has a matching coin ID.
This means if the user switches the UI to something like DOGE-USD, BCH-USD, or MATH-USD, the header can show market cap and volume for the selected asset without fetching the entire world of assets every few seconds.
9. Deposits, withdrawals, lots, and basis trackingUTT is not only a trading screen. It is also developing into a local crypto activity ledger.
The current ledger system includes:
- asset deposits
- asset withdrawals
- basis lots
- FIFO lot consumption
- lot journal entries
- transfer-out impact
- transfer-in linking
- missing-basis flags
- realized P&L support paths
The purpose is to connect trading activity, wallet movement, and cost basis into one local system instead of relying entirely on manual spreadsheets.
A key design principle is that transfers should be treated differently from sells. Moving an asset from one wallet or venue to another should not automatically be treated as a taxable sale. Instead, the system should preserve basis movement across transfer records where possible.
10. All Orders and tax/net fieldsThe All Orders table is intended to unify activity across sources. It can show net values, fee-adjusted values, and tax/net-after-tax style columns. The project has also been working on making realized/tax fields safer so blank/missing values do not distort the interface.
The bigger goal is to eventually have one table where a user can see:
- what happened
- where it happened
- when it happened
- what venue or wallet was involved
- what the gross/net value was
- what fees applied
- what basis was used
- what realized gain or missing-basis issue exists
11. Local backups and safety workflowUTT includes a local backup direction for the SQLite database. This matters because the database is the source of truth for local settings, token registry rows, snapshots, lots, deposits, withdrawals, and other state.
The project emphasizes:
- keep secrets out of Git
- keep database files out of Git
- use local backups
- avoid committing runtime artifacts
- avoid hardcoded private keys
- prefer local profile/API-key management
Why build something like this?Crypto users often end up with a fragmented operational setup:
- exchange balances in one place
- wallet balances somewhere else
- DEX trades in another app
- tax lots in a spreadsheet
- explorer history in a browser tab
- API keys in environment files
- market cap and volume data on external sites
- manual notes for deposits and withdrawals
UTT is trying to reduce that fragmentation.
The idea is not to replace every exchange or every wallet. The idea is to provide a local command layer that lets the user unify their own data and workflows.
For example, a user might want to know:
- What do I currently hold across CEX accounts and self-custody wallets?
- What is my total USD value if wallet snapshots are included?
- Which assets do I own that have market cap and volume data?
- Which deposits still need cost basis?
- Which withdrawals are transfers rather than sales?
- Which orders are still open?
- Which swaps were confirmed on chain?
- Which assets are in my Token Registry?
- Which chain-specific IDs, mints, or decimals belong to those assets?
That is the type of operational visibility UTT is aiming for.
What makes UTT different from a normal portfolio tracker?UTT is not only a price tracker. It is being built as a terminal and ledger engine.
A normal portfolio tracker might show balances and prices. UTT is being designed to connect:
- balances
- orders
- fills
- DEX swaps
- wallet addresses
- deposits
- withdrawals
- basis lots
- market metadata
- local API-key management
- token registry data
It also has a stronger local-first bias. Rather than everything being cloud-account based, the current UTT model is intended to run from the user's own machine, with local configuration, local database state, and local backups.
Current development roadmapThe latest completed baseline includes the Market Cap / Volume tooltabs and improved wallet-inclusive AppHeader portfolio totals.
The next major roadmap section is Hydration wallet-history ingestion:
- discover Hydration wallet history
- classify inbound and outbound transfers
- cache transaction rows safely
- materialize deposits
- materialize withdrawals
- queue missing-basis records
- link bridge transfer records
- preserve cost basis across transfers where possible
After that, there is a planned revisit of Hydration SDK pricing, but only with a safer architecture:
- one persistent SDK context/cache
- no per-pair/per-refresh SDK hammering
- all UI prices served from a stateful local cache
- rate limits respected by design
UTTT and project alignmentUTTT is the project token associated with UTT. The broader idea is to build an open-source aligned trading terminal and ecosystem around it, rather than a closed corporate terminal controlled by a centralized company.
The project has also explored multichain token presence, including Solana and Polkadot Asset Hub / Hydration related work. The purpose is to connect the terminal, the token registry, DEX routing, liquidity workflows, and self-custody visibility into one coherent project.
Again: this is not financial advice, and this should not be read as a promise of profit, a security offering, or a managed investment scheme. UTT/UTTT is best understood as an experimental open-source project and local-first crypto tooling effort.
Who is this for?UTT is mainly for crypto power users, builders, traders, token project operators, and self-custody users who want more control over their own data.
It may be useful for people who:
- use multiple exchanges
- hold assets in multiple wallets
- want a local database of their activity
- care about deposits and withdrawals as separate ledger events
- need to track missing cost basis
- want DEX and CEX activity in one interface
- want market cap and volume context inside the terminal
- want to avoid putting everything into a cloud service
It is probably not for someone who wants a one-click beginner trading app. It is closer to a workstation: powerful, local, configurable, and still evolving.
Current state and transparencyThis is active development software. Some parts are working, some parts are experimental, and some parts are intentionally gated or disabled by default until they are safe.
Examples:
- Market Cap / Volume tooltabs are now working and published.
- Self-custody wallet snapshots can contribute to portfolio totals.
- Token Registry external price metadata is used before backend fallbacks.
- CoinGecko selected-symbol auto-resolution works for assets like MATH.
- Solana/Jupiter DEX paths are wired, but DEX operations should still be tested carefully.
- Hydration wallet-history ingestion is the next major work item.
- Broad Hydration SDK quote hammering is intentionally avoided.
The project is being built iteratively, with a strong preference for surgical changes, tested baselines, and preserving known-good behavior between releases.
Final summaryUTT is a local-first Unified Trading Terminal for crypto users who want one place to manage and inspect multi-venue activity, self-custody balances, token metadata, market data, DEX workflows, deposits, withdrawals, and cost-basis records.
It is not just a portfolio tracker and not just a trading screen. The long-term goal is a local crypto operations terminal: exchange data, wallet data, DEX data, ledger data, and market data unified into one system that the user controls.
The latest published baseline includes Market Cap and Volume tooltabs, DB-owned asset discovery, Token Registry price-source resolution, CoinGecko selected-symbol auto-resolution, wallet-inclusive portfolio totals, and README cleanup.
The next development focus is Hydration wallet-history ingestion: deposits, withdrawals, basis queue handling, and bridge transfer records.
Project direction: local-first, multi-venue, self-custody aware, DEX-aware, ledger-aware, open-source aligned crypto terminal tooling.
Updated
- Hydration price-cache status classifications
- /hydration/prices/status safe polling docs
- cache-only vs controlled-refresh behavior
- sidecar quote-cache / singleflight / backoff docs
- SDK fallback disabled-by-default language
- generic Hydration router quote/orderbook blocking docs
- UTTT-HDX manual sell exact-in and buy exact-out docs
- ASCII-safe source label: derived:UTTT-HDXxHDX-USD
