Revamping Napier App: Our Product Design in On-Chain Finance

Thinking about product design through the goal of bringing all economic activity onchain.

Our approach to product design

Since Napier's founding, our vision has been: “Be the best way to access open financial networks with one effortless click.”

This vision shapes how we design our products. We want users and their agents to understand the assets they hold, the conditions they accept, the systems they depend on, and the actions available to them.

We design our products to connect the structure of a system with the decisions users make. What am I choosing? Which rules apply? Who can change those rules? What happens when I execute an action? These questions guide how we organize information and actions.

The Napier App frontend refresh puts this approach into practice. Choose a market or investment product, understand how it works and under what conditions, then act. We revisited the relationship between navigation, detailed information, and the action panel around this flow.

Today, the app focuses on yield trading. Its design also looks ahead to a broader range of markets and investment products.

Market, Investment, and Vault

We see DeFi as a foundation for combining financial functions, such as exchange, lending, and asset management, into different financial experiences. This is what we mean by a Financial OS.

We therefore distinguish a product's financial purpose from the mechanisms used to carry it out. In designing the interface, we began by clarifying the roles of Market, Investment, and Vault.

A Market is where assets are given prices, interest rates, and trading conditions. The Yield Markets currently available on Napier are one type of Market. Users review a market's conditions and take actions such as trading or providing liquidity.

An Investment combines markets and financial functions into a financial experience that fulfills a defined mandate. That mandate includes an investment policy, operational constraints, and acceptable risks. We consider the full experience: what to invest in, which risks to accept, how capital is managed, and how it is ultimately recovered. The Curator designs and operates that experience.

Managed products in DeFi are commonly called “Vaults,” but we use the term Investment. A Vault refers to the mechanism that executes an investment policy and its constraints. An Investment refers to the complete financial experience delivered to users through that mechanism.

For example, when a Vault allocates capital across several markets, the Vault is the execution mechanism and each Market is an allocation destination. The Investment is the whole arrangement, including its investment policy, risk management, and the conditions for recovering capital.

Napier App provides separate entry points for Market and Investment based on this relationship. In Market, users review market conditions and available actions. In Investment, our aim is to let users understand the policy under which financial functions are combined.

Market information and actions

On the market detail page, information for understanding the market sits on the left, while actions available in that market sit on the right.

The left side shows the underlying asset, maturity, TVL, yields, charts, and other information. With that information in view, users choose how to participate through the panel on the right.

Liquidity, Fixed Yield, and Leveraged Yield are three ways to participate in the same market: provide liquidity, buy PT to earn a fixed yield, or buy YT to take a position on changes in future yield. We group each of these as actions on the selected market.

The action panel separates the assets users put in from the assets they receive. For example, “Deposit (Mint & LP)” shows wsNET as the input and LP tokens and YT as the outputs. Alongside the action's name, users can see how executing it will change their asset holdings.

Choose an object, understand its conditions, then act on it. This is the basic structure of the interface.

Assets, protocols, and Curators

Understanding a market requires several distinct kinds of information.

For a wsNET market, for example, users need to review the market's maturity and fees, how wsNET itself works and its risks, and who operates the market.

We therefore separate detailed information into Market, Asset, and Curator.

Market info shows market settings and related contracts. Asset info covers the underlying asset's issuer, conversion rate, links for deposits and withdrawals, and asset-specific considerations. Curator info identifies the entity that designs and operates the market. Protocols used by the market are also shown separately from the underlying asset and Curator.

This structure is intended to make clear what each condition or risk relates to. Underlying asset risk, market liquidity, protocol permissions, and the scope of a Curator's control are different things. Fee breakdowns and addresses with permissions such as pausing and resuming operations are included to help users assess them.

A shared interface must preserve the differences between products. Even when two products offer a similar deposit flow, how capital is used and when it can be withdrawn may differ. Our approach is to present information consistently while making the differences relevant to a decision explicit.

We want to make the states and dependencies handled by smart contracts and backend systems as readable as possible for both people and agents. Which assets and protocols does a product depend on? Who holds which permissions? Under what conditions is an action available? Organizing information in the interface is one part of making the system's structure understandable and usable for decisions.

Extending the design to Investment

Markets and Vaults share information that users need to review: underlying assets, protocols, Curators, fees, and the conditions for recovering capital.

As we introduce Investments delivered through Vaults, we plan to carry forward the same structure: review information about an object, then act on it. We will also provide the information and actions each product requires, including its investment policy, allocation constraints, and withdrawal or redemption conditions.

Investment listings are currently in development. The navigation includes an entry point, but product listings, detail pages, and actions remain future work.

For us, extensibility means more than being able to add products. It also means users can continue to read the interface in a familiar way. Even when the product changes, they should know where to review its conditions, where to act, and what they will receive. We want to preserve that consistency.

The financial experience also continues after a transaction. We consider how screens connect across reviewing holdings, evaluating results, and recovering capital.

From design to implementation

In this refresh, we translated these product principles into concrete interface decisions: what to present as an object, how to explain its relationships, and where to place the available actions.

Implementing those decisions requires us to determine how to handle market data, shared and product-specific logic, execution requirements, and transaction state. The following three areas of the frontend show how we approach this.

Connecting market information and actions

The market detail page brings market information and transaction actions into one screen.

Both are tied to the selected market, but they serve different purposes. The information area displays charts, market details, metrics, and transaction history. The action panel displays the actions available in that market.

Market data is loaded through shared data-fetching hooks, with additional contract information fetched as needed. Dedicated components and hooks handle the behavior of each action.

This structure lets information views and actions change independently. Users can switch from a chart to the market overview while keeping the transaction form open. Switching from Liquidity to Fixed Yield displays the corresponding form without replacing the entire page.

The selected category and action are managed as application state, and the corresponding form is rendered for that combination. The market remains the shared object connecting the information users are reviewing with the action they intend to execute.

Shared UI, protocol-specific execution

The action panel uses a common structure for Liquidity, Fixed Yield, and Leveraged Yield. The execution method, however, depends on the protocol used by the selected market.

Napier supports different pool implementations, including TOKI-based markets and Curve TwoCrypto markets. Similar user actions may require different contracts, quotes, and transaction execution paths.

Buying PT is one example. When a user selects the purchase action under Fixed Yield, the frontend uses the implementation corresponding to that market. TOKI markets use dedicated quote and transaction hooks, while Curve markets use a separate implementation connected to the existing execution infrastructure.

The Fixed Yield interface remains consistent for the user, while quoting and transaction construction follow each protocol's requirements.

This is the boundary between shared actions and protocol-specific logic. We share the structure for selecting an action and entering inputs, while retaining dedicated components and hooks where execution differs.

The refresh also brings existing trading features into the market detail page. Transaction hooks and protocol integrations continue to be used by both the refreshed interface and the existing standalone action pages. This connects swaps, liquidity management, minting, and redemption to the existing execution infrastructure.

The current implementation does not consolidate every action into a single generic execution path. It provides a shared UI with execution logic for each supported protocol.

Connecting inputs to execution results

Once a user selects an action, the frontend must connect their inputs to a quote, check execution requirements, and display the transaction's progress.

Transaction inputs and outputs are represented as structured information. Each action can define the input assets and amounts, the expected output assets, and minimum amounts received based on the quote.

This structure also supports actions that return multiple assets. For example, when a liquidity action returns several assets, each can be represented separately.

Action buttons and guidance change according to the requirements for execution. If no amount has been entered, the interface prompts the user to enter one. If no wallet is connected, it displays the connection action. If token approval is required, it presents that step before execution.

A paused market, an unavailable action, insufficient balance, or a transaction estimation error can also prevent execution or trigger additional guidance. This ties the actions shown in the interface to the requirements for actually executing a transaction.

After submission, the frontend tracks the transaction's progress and refreshes related data when execution succeeds. This connects the assets shown before execution, the transaction state, and the data displayed afterward.

The design behind “one effortless click”

Delivering the “one effortless click” in our vision requires us to design both ease of use and the information needed to make a decision. What do users hold? Which conditions are they accepting? What changes when they act? We want users and their agents to understand these things before taking action.

In this refresh, we organized the interface around financial objects: their attributes, their relationships to other objects, and their available actions. We see this approach as a foundation for an era in which both people and agents read financial states and conditions and act on them.

We will continue developing this design toward the goal of bringing all economic activity onchain. We hope this work also provides a starting point, and part of a foundation, for thinking about and building financial experiences in the age of AI.