Native

Primary pages: /index, shared header across app routes

This module is the application frame that ties the product areas together and handles first-time access.

What it does

• Provides the global navigation for core areas shown in the header content: “Credit Pools”, “Earn”, “Swap”, “Integration”, “Docs”, “Analytics”.
• Establishes chain context and wallet access. The header copy includes “Ethereum”, implying a default network context at least in the top-level UI.

Visible UI/interaction points

• Button: Connect Wallet (seen on /index and /app/swap-rfq). This is the primary gate for any on-chain actions (deposit, swap, withdraw, etc.).
• Button: Get Integrated (seen on /index and /app/swap-rfq). This is a CTA for partners/builders rather than end users.
• Page-level positioning is consistent: the product description repeats across these pages: > “Native is an on-chain platform to build liquidity that is openly accessible and cost effective.”

Data surfaced (or not)

• No explicit TVL, volume, APR, pool count, supported tokens, or historical charts are visible in the provided page surfaces. From a functional standpoint, the app shell is currently more of a router/entrypoint than a metrics dashboard.

Strategic significance

• The presence of both Connect Wallet and Get Integrated on the main entrypoints suggests a dual audience: traders/LPs and integrators (market makers, wallets, aggregators). The app shell is the platform’s “distribution layer”—it reduces friction to reach credit pools, earn, and RFQ swap while pushing builders toward documentation and analytics resources.

Primary page: /app/credit-pool (Title: Native - Credit Based Liquidity Pools)

This module is positioned as the protocol’s core primitive: credit-based liquidity pools. While the analyzed view does not expose pool tables or parameter panels, the page title and global navigation make it clear this is a dedicated functional area.

What it does (expected from the surface and naming)

• Hosts pool creation/participation flows centered on credit-based liquidity rather than standard AMM-only liquidity.
• Likely enables allocation of liquidity under credit terms (e.g., whitelisted borrowers/market makers, credit limits, or off-chain risk assessment), given the explicit branding “Credit Based Liquidity Pools”.

Visible UI/interaction points

• The page uses the same core product description: > “Native is an on-chain platform to build liquidity that is openly accessible and cost effective.”
• Navigation indicates a user can move between Credit Pools ↔ Earn ↔ Swap, implying this page is the LP side of a system that also supports trading and yield.

Data surfaced (or not)

• In the reviewed screen surface, there are no visible pool rows, APRs, utilization rates, collateral factors, or risk tiers.
• No visible form fields (e.g., deposit amount, token selector) were observed on this page snapshot.

Strategic significance

• Credit pools are typically designed to increase capital efficiency versus passive AMM liquidity by allowing liquidity to be deployed based on borrower quality or market-making arrangements.
• For the platform, isolating this as a standalone module signals a product strategy: liquidity is not just “LP tokens,” but a programmable credit facility that can feed the Earn module (yield distribution) and the Swap/RFQ module (liquidity access for execution).

Primary page: /app/earn (Title: Native - Credit Based Liquidity Pools)

The Earn module represents the user-facing yield surface that sits above the protocol’s liquidity infrastructure.

What it does

• Provides an “Earn” entrypoint from the global navigation (“Earn” appears alongside Credit Pools and Swap). Functionally, this is where users would expect to:
  • Deposit assets into yield strategies linked to credit pools.
  • Track yield accrual, positions, and withdrawals.
  • Potentially choose between strategies (tenors, risk buckets), if the protocol supports credit segmentation.

Visible UI/interaction points

• The page shares the same product framing copy about building accessible and cost-effective on-chain liquidity.
• The analyzed view does not show explicit deposit/withdraw buttons, token selectors, or position tables; however, the presence of a distinct /app/earn route indicates a dedicated stateful app area rather than static marketing.

Data surfaced (or not)

• No explicit APR/APY, TVL, reward token, lockup, or strategy list is visible in the provided surface.
• No tables, charts, or filters were visible in the snapshot.

Strategic significance

• “Earn” is the module that converts the protocol’s liquidity design into a retail/institutional-friendly outcome metric: yield.
• In a credit-liquidity DEX, this module is important for balancing supply/demand: it attracts deposits (liquidity supply) that can be allocated into credit pools, which in turn can support tighter execution on the Swap side.
• The current UI surface looks early-stage or intentionally minimal; for institutional readiness, this module typically benefits from exposing utilization, borrower concentration, and historical realized yield.

Primary page: /app/swap-rfq

This is the trading module. The route name explicitly indicates an RFQ (Request for Quote) flow rather than a pure AMM swap.

What it does

• Provides a swapping surface designed to obtain quotes (typically from market makers or internal liquidity) and execute trades once the wallet is connected.
• Acts as the demand-side consumer of liquidity provisioned through Credit Pools.

Visible UI/interaction points

• Buttons: Connect Wallet, Get Integrated are both present on /app/swap-rfq.
  • Connect Wallet is required for signing and trade execution.
  • Get Integrated indicates the swap system is intended to be embedded by third parties (wallets, aggregators, or partners).
• Header content includes product tabs: “Credit Pools”, “Earn”, “Swap”, “Integration”, “Docs”, “Analytics” plus “Ethereum”, implying chain selection or at least a displayed default chain.

Data surfaced (or not)

• The analyzed surface does not show trade widgets (token in/out selectors, amount input, slippage controls), quote panels, price impact, route info, or an order status timeline.
• No visible market data (price, spread, liquidity depth) appears in the provided snapshot.

Strategic significance

• An RFQ swap interface is commonly used to deliver better execution for larger trades and reduce MEV/price impact relative to open mempool AMMs.
• The explicit split between Swap and Credit Pools suggests Native’s execution is intended to be backed by structured liquidity rather than purely passive AMM liquidity, aligning with a credit-based design.

Primary pages: /native-dev, /native-dev/resources/analytics

This module is the builder-facing surface: documentation, navigation, and official analytics links.

What it does

• /native-dev is a documentation hub titled “What is Native” with a doc-site UI.
• /native-dev/resources/analytics provides an Analytics index that points users to external dashboards and chain-specific contexts.

Visible UI/interaction points

• Search field: Search… (on both doc pages). This indicates a structured doc system with indexed pages.
• Doc UI controls (buttons/icons): bars (sidebar), circle-xmark / xmark (close), chevron-right, chevron-up, chevron-down (navigation), and theme/device toggles: sun-bright, desktop.
• Analytics headings are explicit and actionable:
  • <h1> Analytics
  • <h2> hashtagDefiLlama, <h2> hashtagDune, <h2> hashtagCoinGecko
  • Chain subsections: <h4> hashtagEthereum, <h4> hashtagBsc, <h4> hashtagArbitrum, <h4> hashtagBase

Data surfaced (or not)

• No on-page charts are shown in the analyzed view; the module appears to route users to third-party sources (DefiLlama/Dune/CoinGecko) for TVL, volume, and market data.

Strategic significance

• For a DEX with credit-based liquidity, credibility and transparency are often established via independent analytics. Linking DefiLlama/Dune/CoinGecko and enumerating multiple chains suggests an intent to support multi-chain monitoring and integrator due diligence.
• The Get Integrated CTA elsewhere in the app pairs with this module: the docs + analytics hub is the operational toolkit for partners integrating swap or liquidity functionality.