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

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

IMPORTANT: A small mismatch in signature/decimals can break pricing/accounting. Always verify against the resolver specification before deployment.

---

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.