Balancer

What it does

• The /swap page is the primary execution surface for token swaps across supported networks (page description explicitly lists Ethereum, Optimism, Arbitrum, Base).
• It’s optimized around wallet-gated execution: the only visible CTAs are “Create wallet” and “Connect”, indicating swap inputs and route quoting are likely hidden/disabled until a wallet + network context is present.

Observed UI/interaction signals

• Minimal visible chrome suggests a “single-task” swap UI that prioritizes conversion over discovery.
• The lack of explicit form fields in the visible headings/buttons implies the page conditionally renders the swap form after session prerequisites (wallet connection, chain selection) are met.

Strategic significance

• Swap is the protocol’s highest-frequency workflow. By keeping the entry surface thin and gating with Connect, the product reduces user error (wrong network, missing approvals) and pushes stateful logic into wallet/session management.
• The page positioning (“Swap tokens on Balancer”) reinforces Balancer as an execution venue rather than only a pool directory. This is important because Balancer’s routing may depend on pool types (including v3 hooks and novel invariants) while the user only sees a standard swap action.

Notes for integrators

• The user-facing swap surface is paired with developer routing docs (see /build/build-a-router/create-custom-router/html), suggesting Balancer expects sophisticated routing strategies behind a simple UI.

What it does

• /pools is the discovery hub for providing liquidity and comparing pools by yield and activity.
• The page frames the value prop: “Provide liquidity to accumulate yield from swap fees while retaining your token exposure.”

Concrete data points visible

• Pool directory shows a count: “Liquidity pools (5,755)”.
• Sorting/metrics controls are exposed as buttons: “TVL”, “Volume (24h)”, “APR”.
• Yield examples appear in the UI: “2.25% - 2.57%” and “1.20%” (likely sample APR chips or selected pool cards).
• Featured ecosystem integrations are called out with dedicated headings: “QuantAMM”, “CoW AMM”, “Gyroscope”.
• A launch banner indicates network expansion: “Balancer is live on Monad”.

Interactive elements

• “Filters” button suggests a faceted search over pool attributes (chain, tokens, pool type, incentives).
• “Connect” / “Create wallet” indicates personalized data (positions, eligibility) becomes available post-connection.

Strategic significance

• This module is the marketplace: it translates protocol complexity (many pool designs and chains) into a sortable catalog.
• Highlighting partner AMM designs and new deployments (e.g., Monad) positions Balancer as a platform for heterogeneous liquidity, not a single invariant product.

What it does

• /create is a guided flow to deploy a new Balancer v3 pool.
• The page is structured as a stepper with sections labeled “Type”, “Tokens”, “Details”, “Fund”, matching the headings shown on-page.

Form structure and controls

• Repeated headings “Pool type” and “Tokens” appear both as step labels and detailed sections, implying a two-level UI: step navigation + configuration panel.
• A “Pool preview” panel is explicitly listed, indicating real-time validation/summary (e.g., token list, weights/params, initial liquidity requirements).
• Wallet-dependent inventory is surfaced via “Pool tokens in my wallet”, which implies token selection and funding checks are computed from connected wallet balances.

Operational controls

• CTAs: “Connect”, “Connect wallet” (both appear), plus recovery actions “Delete & restart” and support entry “Get help”.
• The presence of hard reset suggests multi-field state that can become invalid (token decimals, allowances, min initial liquidity), so a clean restart is treated as a first-class action.

Strategic significance

• Pool creation is the supply-side growth lever. By making v3 pool deployment a productized wizard, Balancer reduces the cost of launching bespoke liquidity venues.
• The explicit preview and wallet token inventory reduce failed transactions and misconfigured pools—critical because deployment and initial funding are irreversible, on-chain operations.

What it does

• /portfolio consolidates a user’s Balancer positions, incentives, and staking-related views.
• The main header “My Balancer liquidity” indicates this is the default landing for connected accounts.

Concrete data points visible

• In the observed (disconnected or empty) state, the totals show “$0.00” for liquidity.
• Incentives are broken out as a distinct block: “Claimable incentives” with “$0.00” shown (appears twice in headings, suggesting separate categories or duplicated panels for multiple incentive sources).
• Multi-chain tabs are explicit: “Ethereum”, “Arbitrum”, “Base”.

Controls and segmentation

• Buttons include “Filters”, “Staking”, “veBAL boost”, “My liquidity”, “APR”, and “Connect wallet”.
• This implies the page is not just a passive dashboard: it likely routes into deposit/withdraw, staking, and boost flows, with filters for pool types, chains, and incentive programs.

Strategic significance

• Portfolio is the retention surface: it translates protocol participation into an account-level P&L and rewards experience.
• Explicit chain segmentation reduces confusion as Balancer expands across L2s and new EVM chains.
• The dedicated veBAL boost entry aligns the user with governance-linked incentives, steering liquidity providers toward longer-term alignment rather than pure mercenary yield.

What it does

• /vebal explains and likely executes the veBAL locking/boost workflow.
• The page framing is practical: “Lock-in for veBAL boosts” and “Why get veBAL?” with clearly enumerated benefits.

Benefits explicitly listed

• “Vote on Balancer's future” (governance power)
• “Share protocol revenue” (economic rights)
• “Earn weekly voting incentives” (bribes/incentives market)
• “Boost liquidity mining yield” (LP rewards multiplier)

Step-by-step process UI

• The module documents a 3-step flow under “Here’s how it works”: 1) “Add liquidity” 2) “Lock your LP tokens” 3) “Get power + rewards”
• Top-level actions are wallet-gated via “Create wallet” and “Connect”.

Strategic significance

• veBAL is the protocol’s alignment primitive: it ties rewards and governance to time-locked participation.
• By presenting veBAL as a boost mechanism (not just governance), Balancer reduces the barrier for LPs who care about APR optimization.
• The explicit revenue-sharing and incentive earning statements position veBAL as a yield-bearing governance asset, which is important for institutional participants evaluating long-term protocol cashflows and control rights.

What it does

• Balancer’s docs under /concepts and /build describe a programmable AMM platform rather than a fixed set of pool contracts.
• The developer surface splits into: concepts, extensibility (hooks), routing, novel invariants, and analytics indexing.

Core concept entry

• /concepts/core-concepts/introduction/html provides “What is Balancer?” and links to “Helpful Articles to Learn More”, functioning as the top of the technical funnel.

Extending pools via hooks

• /build/build-a-hook/extend-existing-pool-type/html is a practical recipe: “Creating a Dynamic Swap Fee Hook Contract”, “Setting Hook Configuration”, “Hook Registration”, and “Implementing the Swap Fee Logic”.
• This indicates hooks are first-class modules that can be registered/configured against existing pool types to change runtime behavior (e.g., dynamic fees).

Custom router

• /build/build-a-router/create-custom-router/html focuses on “Usage”, implying Balancer expects integrators to implement routing logic suited to their order flow (RFQ, aggregators, intent-based routing).

Custom AMM with novel invariant

• /build/build-an-amm/create-custom-amm-with-novel-invariant/ht details math and lifecycle: “Compute Invariant”, “Compute Balance”, “On Swap”, “Constructor arguments”, plus sections on “Swap fees”, “Hooks”, “Vault reentrancy”, and “Add / Remove liquidity”.
• Buttons referencing “Constant Product Pool” and “Constant Sum Pool” suggest templates or comparisons.

Subgraph module

• /data-and-analytics/data-and-analytics/subgraph/html lists “V3 Subgraphs” with “Vault Subgraphs” and “Pools Subgraphs” and a table with columns Network | Production URL | Development URL (rate-limited), making indexing endpoints operationally explicit.

Strategic significance

• This module is Balancer’s moat: programmable liquidity (hooks + custom invariants) and an explicit data layer (subgraphs) enable third-party products to build differentiated execution and pool designs while staying inside the Balancer ecosystem.

What it does

• /partner-onboarding/onboarding-overview/introduction/html is a structured pathway for teams integrating or launching on Balancer.
• It combines education (“Balancer Technology”, “Unique AMM Designs and Products”) with process guidance (“High-Level Overview of Onboarding Process”, “Onboarding Journey”).

Product selection tool

• The page explicitly advertises “Balancer Product Wizard 🧙‍♂️”, indicating a guided decision flow rather than static documentation.
• The visible selection CTAs map to concrete partner use cases:
  • “Governance Token Liquidity”
  • “Index Products or Multi-Token Pools”
  • “Custom Pool Logic or Extensions”
  • “LVR Protection”
  • “Token launch”

Deployment context

• There is a section “Balancer Deployments” with at least “Balancer v2” referenced, suggesting the onboarding content differentiates between versions and directs partners to the right stack.

Strategic significance

• This module operationalizes BD + engineering: it reduces integration ambiguity by translating partner goals into product tracks.
• The presence of “Custom Pool Logic or Extensions” connects directly to v3 hooks/custom AMM docs, while “Token launch” and “LVR Protection” frame Balancer as infrastructure for launches and MEV-aware liquidity.
• For institutional partners, this page acts as a requirements triage: it clarifies which Balancer product line to use before deep technical implementation begins.

What it does

• These pages handle legal consent and edge-case access interruptions that still affect conversion and user trust.

Cookies policy

• /cookies-policy provides a formal “Balancer Cookies Policy” with structured sections:
  • I. Introduction and Scope of Policy
  • II. About Cookies
  • III. Do You Have to Accept Cookies?
  • IV. Additional Technologies
  • V. Using Information
  • VI. Sharing
• Despite being a legal page, it still contains product CTAs “Create wallet” and “Connect”, implying persistent header actions across the site and the need to keep wallet flows accessible even from compliance content.

Security checkpoint

• /index resolves to “Vercel Security Checkpoint”, indicating an upstream protection layer (anti-bot, DDoS, or risk-based traffic gating).

Strategic significance

• Consent management (cookies) is necessary for analytics/marketing compliance and for operating in stricter jurisdictions.
• A security checkpoint at the entry route is materially important for uptime and fraud prevention; however, it can also introduce friction for power users and integrators if it triggers unexpectedly.
• Keeping wallet CTAs present on policy pages helps avoid dead-ends during onboarding, preserving conversion paths even when users are reading legal disclosures.