Nest

Purpose / what it does

• The main execution surface lives at /trade/swap (title: Swap). It provides token-for-token swapping with integrated pricing and risk disclosures.
• A top-level nav preview shows the product areas: Trade, Dashboard, Liquidity, Lock, Vote, Incentivise, Analytics.

Visible UI + key features

• Primary CTA: “Connect your wallet” (also seen across the app).
• Swap composition includes Sell and Buy panels with quick-sizing buttons Half / Max and an “Enter amount” trigger.
• Form fields indicate multi-representation input: “Select amount | $ | %”.
• A “View chart” button suggests an embedded price chart modal/panel (not shown elsewhere).

Transaction diagnostics (explicitly shown)

• A Transaction details block exposes:
  • Minimum Amount Received
  • Slippage 0.1% (explicit default displayed)
  • Price Impact with a hard warning: > “price impact greater than 5%” message
  • Rate

Strategic significance

• This module is the conversion funnel: everything else (liquidity, locking, voting incentives) exists to improve execution quality and distribute value.
• The built-in slippage + price impact warning indicates focus on protecting users from thin liquidity conditions—important given the “deepest liquidity” positioning in the /trade/swap description.

Related routes

• Several sub-pages under /trade/swap/ (/swap, /trade, /earn, /farm, /liquidity, /pool, /portfolio, /stake) render as a minimal Nest Exchange shell with “Go home” + “Connect your wallet”, implying these features are planned but not yet fully implemented in this build.

Purpose / what it does

• /liquidity (title: Liquidity) is positioned as the hub for LP-related workflows (adding/removing liquidity, viewing pools), though the provided page snapshot contains only the page metadata.

What’s observable from IA / navigation

• Liquidity is a first-class module in the global navigation (preview text includes Liquidity alongside Trade/Lock/Vote).
• The presence of /trade/swap/liquidity and /trade/swap/pool routes (even as shells with “Go home”) indicates a split between:
  • a standalone Liquidity page (/liquidity) for canonical LP actions
  • and embedded liquidity/pool views inside the Trade area for quicker discovery.

Interactive elements & expected primitives (based on adjacent modules)

• While /liquidity doesn’t expose fields in the captured data, the rest of the app uses consistent controls:
  • Wallet gating (Connect your wallet)
  • Amount sizing helpers (Half, Max)
  • Tab-like filters (seen in /vote)
• This suggests the Liquidity module likely follows the same patterns: token selectors, amount inputs, and position tables once connected.

Strategic significance

• Liquidity is the supply-side engine for the swap module: deeper pools reduce price impact and make the 0.1% slippage default more realistic across pairs.
• The coexistence of pool-related routes under /trade/swap implies a product strategy of pairing execution (swap) with immediate LP actions (pool/liquidity) to capture users who see poor pricing and want to provide liquidity.

Gaps / current state

• In this build, the dedicated /liquidity content is not exposed in the snapshot; combined with multiple “Go home” shells under /trade/swap, LP operations appear partially staged rather than fully surfaced end-to-end.

Purpose / what it does

• Governance is split into:
  • Lock creation at /lock/create (New Automatic Lock)
  • Voting at /vote (Vote) for pool-level decisions.

/lock/create: Lock workflow details

• Headings: “New Automatic Lock” and “Time locked” indicate time-based escrow.
• Buttons reveal operational modes:
  • Calculator (likely previews resulting voting power / lock outcome)
  • Automated vs Manual (two UX paths; automation could imply renewal/compounding or scheduled actions)
  • Amount helpers: Half, Max
• Form field shows numeric input placeholder 0.00, consistent with a token amount entry.
• Wallet gating is prominent: Connect your wallet / Connect wallet.

/vote: Vote surface details

• Heading: “Vote” with wallet-gated actions (Connect your wallet, Connect wallet).
• Filter controls suggest pool browsing and sorting:
  • All Pools, Highest APR
  • Pool-type filters: Concentrated, Stable, Classic
  • Pagination: Previous

Strategic significance

• This module is the control plane for emissions and incentives routing (reinforced by the separate Incentivise page). A lock → vote loop typically drives long-term alignment by requiring time commitment to influence rewards.
• The explicit pool-type filters indicate Nest expects heterogeneous AMM designs (concentrated vs stable vs classic) and wants voting decisions to be made with those categories in mind.

What’s missing in the captured UI

• No explicit lock duration picker, ve-balance output, or vote weight sliders are shown in the snapshot; however, the presence of Calculator and Time locked strongly implies those details exist behind wallet connection or in subsequent steps.

Purpose / what it does

• /incentivise (title: Voting Incentives) provides a mechanism to add incentives to influence how votes are allocated (commonly “bribes” targeted at specific pools/epochs).

UI elements that expose functionality

• Primary CTA: Connect your wallet (wallet-gated submission).
• Amount input uses a numeric field with placeholder 0.00.
• Quick-fill controls: Half and Max mirror the swap/lock patterns, implying incentive deposits are token-amount based.

Workflow implied by the page

• Although no pool selector is shown in the provided snapshot, the page title and its proximity to /vote suggest a typical flow: 1) Choose a target gauge/pool (likely a dropdown/table once connected) 2) Enter incentive amount (0.00 input; Half/Max helpers) 3) Submit on-chain transaction (wallet required)

Strategic significance

• This module externalizes demand for vote share: protocols or pool creators can pay to attract emissions, improving liquidity where it’s most valued.
• Separating Incentivise (/incentivise) from Vote (/vote) reduces clutter in the voting UI while keeping governance legible: voters allocate power; third parties compete by funding incentives.

Current-state observations / constraints

• No APR/TVL numbers or incentive schedules are visible in this snapshot, so users currently can’t validate competitiveness directly on this page.
• Given the consistent design language (Half/Max, wallet gating), the module is structurally ready, but key discovery elements (target pool list, epoch timing, minimum deposit) are not evidenced in the provided view.

Purpose / what it does

• /analytics (title: Analytics) provides platform-wide reporting and a specialized vault view for the “HYPE Engine”.

Concrete UI / data affordances

• Headings explicitly define scope:
  • “Analytics”
  • “HYPE Engine Vault Analytics”
  • “Compounded Rewards” (appears twice as an h3, suggesting two panels/cards for reward views)
• Time range controls are present as quick filters:
  • 1W, 1M, 3M, 1Y
• Pagination / step controls:
  • Previous, Next (likely cycling chart windows or moving through vaults/epochs)
• Access is wallet-gated only for actions, not for viewing: Connect your wallet is still present, but analytics pages typically render read-only metrics without connection.

What this implies technically

• The time filters and Previous/Next controls suggest charting components with discrete windows (e.g., weekly/monthly series) and stateful navigation.
• The repeated “Compounded Rewards” headings imply either:
  • two different reward streams (e.g., base + boosted), or
  • the same metric shown for different assets/timeframes.

Strategic significance

• This module is the proof layer for the DEX’s value proposition (“HYPE-Aligned MetaDEX”): it shows whether the vault strategy and reward compounding are actually delivering.
• In a governance-driven system, analytics also supports decision-making: voters and incentivisers need performance visibility to allocate votes/incentives rationally.

Data gaps in the captured view

• No explicit numeric KPIs (TVL, APR, fees, volume) are visible in the snapshot; the module provides structure for analytics, but the disclosed page text doesn’t expose the actual figures.

Purpose / what it does

• /dashboard (title: Position Balances) is the user-centric accounting page: it aggregates positions and platform rewards.
• The page description is explicit: “Track all your positions and accumulated platform rewards in real time.”

UI elements

• Heading: “Position Balances”.
• A secondary heading/empty-state prompt: “Connect your wallet”.
• Single primary action: Connect your wallet.

Implied data model

• The wording “positions” + “accumulated platform rewards” suggests the dashboard is expected to unify:
  • swap-related holdings (wallet balances)
  • LP positions (from /liquidity)
  • lock/vote state (from /lock/create and /vote)
  • claimable rewards (potentially tied to the HYPE Engine Vault in /analytics)
• “Real time” implies live refresh on new blocks/events or periodic polling once connected.

Strategic significance

• This page reduces fragmentation: without a consolidated dashboard, users must hop between Trade/Liquidity/Lock/Vote to understand net exposure.
• It is also the retention surface: rewards accumulation visibility increases repeat engagement and drives users back into compounding/locking/voting loops.

Current-state observation

• In the captured view, the dashboard is effectively gated behind wallet connection with no preview tables (e.g., positions list, rewards breakdown, PnL). From a functional standpoint, the module exists as an entry point but its on-page components are not evidenced without connecting.