> For the complete documentation index, see [llms.txt](https://docs.trybasket.live/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trybasket.live/how-basket-works/minting-redemption-and-pricing.md).

# Minting, redemption & pricing

This page shows how value enters, how it exits, how price anchors to NAV, and how live allocations drift.

### Flow overview

{% tabs %}
{% tab title="Mint" %}

#### Investment flow

An investor can deposit ETH or another token.

Basket routes that value into Base WETH, buys the basket's constituents at target weights, and mints basket tokens against the new backing.

```mermaid
flowchart LR
    A[Investor wallet] --> B[Basket router]
    B --> C[Convert input to Base WETH]
    C --> D[Basket pool]
    D --> E[Buy constituents at target weights]
    E --> F[Pool receives backing assets]
    F --> G[Mint basket B20 token]
    G --> H[Investor wallet]
```

{% endtab %}

{% tab title="Redeem" %}

#### Redemption flow

The investor burns the basket token, the pool releases the matching value, and that value can leave as pro-rata constituent output or be routed through WETH into one chosen token.

```mermaid
flowchart LR
    A[Investor wallet] --> B[Burn basket token]
    B --> C[Basket pool]
    C --> D[Release pro-rata constituent value]
    D --> E[Return constituents to wallet]
    D --> F[Optional route through Base WETH]
    F --> G[Return one chosen token]
```

{% endtab %}
{% endtabs %}

### Why WETH sits in the middle

Basket uses Base WETH as the routing asset.

That keeps quoting and execution paths cleaner.

It also aligns with common liquidity on Base.

### Why supply stays aligned

Minting only happens after backing enters the pool.

Burning happens before value leaves the system.

That keeps the claim and the backing aligned in both directions.

| Step                       | On-chain effect                       |
| -------------------------- | ------------------------------------- |
| Deposit enters the router  | Input asset is received for execution |
| Router converts into WETH  | Routing standardizes around one asset |
| Pool acquires constituents | Backing assets enter the pool         |
| Basket token mints         | Supply increases against backing      |

### NAV and the pricing anchor

NAV is the value of the assets held in the pool.

Per-token NAV is that value divided by basket token supply.

Open mint and redeem flows create the arbitrage loop that can pull market price toward redeemable value.

{% hint style="warning" %}
Basket is fully collateralized.

It is not a bonding curve.
{% endhint %}

### Target weights and live allocations

Target weights describe the intended portfolio shape.

Live allocations reflect market reality until new flows or rebalancing pull the basket closer to target.

| Pattern          | Strength                     | Weakness                      |
| ---------------- | ---------------------------- | ----------------------------- |
| Equal weight     | Easy to understand           | Can overweight smaller assets |
| Market-cap aware | Intuitive for broad exposure | Can entrench incumbents       |
| Custom           | Expressive                   | Demands stronger explanation  |

### Rebalancing

Even a fixed recipe drifts as token prices move.

Rebalancing restores the basket closer to target.

Managed baskets can also redefine the target itself.

| Model           | How it works                              | Tradeoff                       |
| --------------- | ----------------------------------------- | ------------------------------ |
| Schedule-based  | Changes happen at set times               | Predictable but blunt          |
| Threshold-based | Changes happen after drift passes a limit | Efficient but less predictable |
| Discretionary   | Creator decides when to act               | Flexible but trust-heavy       |

### Costs that sit on top

NAV is a value anchor.

It is not the same as your exact execution price.

Gas, route quality, and any protocol or creator fees still affect the final quote.

<details>

<summary>Why Basket uses one routing asset</summary>

Using one intermediate asset simplifies quoting and market execution.

It also avoids building direct routes from every input asset into every constituent.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.trybasket.live/how-basket-works/minting-redemption-and-pricing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.