# 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**.
Here we visualize which resolver to choose based on the underlying asset

Here we visualize which resolver to choose based on the underlying asset

### Base Case (A): ERC-4626 Resolver This is the **reference model**. 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*. > > 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**.