# Resolver Selection

A resolver is a code template that supports \~99.9% of underlying yield-bearing assets and enables the **permissionless** creation of Napier Markets.

All resolvers solve the same problem:

> **Convert shares (underlying) into assets (value unit).**

They differ only in **where the conversion logic comes from** and **how explicit that logic must be**.

This section is organized to highlight **what stays the same** and **where each resolver diverges**.

<figure><img src="/files/s1r5TvfcZNBc9aSisXGs" alt="Here we visualize which resolver to choose based on the underlying asset"><figcaption><p>Here we visualize which resolver to choose based on the underlying asset</p></figcaption></figure>

### Base Case (A): ERC-4626 Resolver

This is the **reference model**.&#x20;

All other resolvers diverge from this baseline in specific ways.

#### What A assumes

* The underlying is a **standard ERC-4626 vault**
* The vault itself defines:
  * the asset
  * the share-to-asset conversion logic

#### Inputs

* **Vault address**

#### Conversion logic

```
assetAmount = convertToAssets(shareAmount)
```

This is the **most standardized and constrained** resolver.

***

### Variant (B): Share Price Resolver

**B matches A conceptually, but drops standardization.**

#### What B shares with A

* Conversion is still **share-based**
* A clear concept of **share price** exists
* Asset value is derived by multiplication

#### Where B diverges from A

* ❌ Not ERC-4626
* ❌ No standardized interface
* ✅ Share price is exposed via a custom function

#### Additional inputs (compared to A)

* **Function name** (e.g. `exchangeRate()`, `sharePrice()`)
* **Asset address** (explicitly specified)

#### Conversion logic

```
assetAmount = shareAmount × sharePrice
```

**Key difference from A:**

> A standardizes *how* the share price is retrieved.
>
> B requires you to explicitly specify *where* the share price comes from.

***

### Variant (C): Custom Conversion Resolver

**C diverges earlier by abandoning the share price model entirely.**

#### What C shares with A and B

* The goal is still **share → asset conversion**
* Conversion logic remains on-chain

#### Where C diverges from A and B

* ❌ No share price
* ❌ No multiplication model
* ✅ Direct **amount-in → amount-out** conversion

#### Inputs

* **Vault address**
* **Function name** (conversion function)
* **Asset address**: base asset address

#### Conversion logic

```
assetAmount = conversionFunction(shareAmount)
```

**Key difference from B:**

> B returns a *price per share*.&#x20;
>
> C returns the *asset amount directly*.

***

### Variant (D): External Price Oracle

**D abandons native conversion logic and relies on external pricing.**

This category applies only when the underlying token provides **neither**\
a conversion function nor a share price function.

#### What D shares with A–C

* Asset value is still derived from a share amount

#### Where D diverges

* ❌ No native conversion or pricing logic
* ✅ Value is inferred from an external oracle

#### Variant (D1): Price Oracle Feed (ChainlinkPriceResolver)

Use when the price feed is compatible with\
`AggregatorV3Interface`.

#### Inputs

* `vault`: underlying token address
* `asset`: base asset address
* `oracle`: price feed from Chainlink/Redstone/etc..

***

### Edge Case (E): Fixed (Constant) Price Resolver

**E removes pricing dynamics completely.**

#### What E shares with others

* A direct mapping from share to asset

#### Where E diverges

* ❌ No function
* ❌ No oracle
* ❌ No variability

#### Inputs

* **Asset address only**

#### Conversion logic

```
assetAmount = shareAmount
```

***

### Edge Case (F): Rebasing Tokens

If the underlying token is **rebasing** (wallet balances change automatically):

* ❌ **Not supported natively**

(Use a non-rebasing wrapper or contact the team.)

***

### Wrapped Native Asset Requirement

Resolvers only support **ERC-20 tokens**.

If the underlying uses a native token (ETH, AVAX, etc.), you must set `asset` to the **wrapped ERC-20 version** of that token.

* Native tokens **cannot** be used directly
* Always use the **canonical wrapped token** on the chain (e.g. WETH)

#### Examples

* **Ethereum**: WETH `0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2`
* **Optimism**: WETH `0x4200000000000000000000000000000000000006`
* **BSC**: WBNB `0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c`
* **Polygon**: WMATIC `0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270`
* **Sonic**: WS\_SONIC `0x039e2fB66102314Ce7b64Ce5Ce3E5183bc94aD38`
* **Fraxtal**: WFRXETH `0xFC00000000000000000000000000000000000006`
* **HyperLiquid**: WHYPE `0x5555555555555555555555555555555555555555`
* **Mantle**: WMNT `0x78c1b0C915c4FAA5FffA6CAbf0219DA63d7f4cb8`
* **Base**: WETH `0x4200000000000000000000000000000000000006`
* **Arbitrum**: WETH `0x82aF49447D8a07e3bd95BD0d56f35241523fBab1`
* **Avalanche**: WAVAX `0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7`

***

### Additional Requirements and Safety Notes

Resolvers and the underlying conversion/price sources are treated as **trusted inputs**.

* The resolver **does not validate freshness/staleness** of any conversion rate or oracle price.
* A resolver **cannot be upgraded or modified after deployment**.
* The resolver assumes conversion/price functions:
  * **always return valid, up-to-date values**
  * **never revert**
  * match the expected **function signature and return types exactly**

{% hint style="danger" %}
**IMPORTANT:** A small mismatch in signature/decimals can break pricing/accounting. Always verify against the resolver specification before deployment.
{% endhint %}

***

### Final Pre-Deployment Checklist

Before deploying a market:

1. Confirm the token is **not rebasing**.
2. Confirm resolver selection via the flow:
   * ERC-4626 → Custom Conversion → Share Price → Oracle (Chainlink/External) → Constant
3. Verify:
   * function signature matches exactly
   * return type and scaling/decimals match expectations
   * function never reverts
4. Treat the chosen conversion/price source as **immutable trusted infrastructure**.


---

# Agent Instructions: 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:

```
GET https://docs.napier.finance/curate/napier-curation/create-market-napier-amm/resolver-selection.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.