NMPIP 243: Protocol Pricing Parameter Adjustments, Features

NMPIP 243: Protocol Pricing Parameter Adjustments, Features

Overview

During the Nexus Mutual team offsite, we established the engineering priorities for Q4 2024 that include adjustments to certain pricing parameters and added functionality for fixed-price public listings.These adjustments and added functionality are related to new product types the team is currently developing–one of which is nearing a soft launch release.

On behalf of the Product & Risk team, I propose that members grant the Advisory Board the authority to execute several proposals that would:

  • Decrease the PRICE_BUMP_RATIO parameter from 20 to 5 to reduce the rate at which a listing’s price increases after a cover buy
  • Remove Surge Pricing from the protocol’s existing price calculations
  • Change the Global Min Price to the Default Min Price
  • Create functionality to set a Min Price at the listing level, which will be called the Listing_Min_Price
  • Create functionality for public fixed-price listings that any pool manager can stake against

Rationale

Growth is the primary objective for the Mutual over the next year. To support growth in cover sales, the Foundation and DAO teams have discussed what protocol and product changes can support growth in sales in the next year. I’ll outline below how each change supports growth and improves UX for cover buyers.

Decrease the PRICE_BUMP_RATIO Parameter from 20 to 5

When a member comes and buys a decent percentage of the available capacity for a listing, the price tends to increase to a degree that it prevents others from buying cover for one or more days until the price approaches the min price set by the pool managers. The PRICE_BUMP_RATIO is intended to prevent pool managers from mispricing risk and to spread cover buys across staking pools. However, during less active periods we are seeing the price spike when people buy cover in size that deters others from purchasing cover.

By decreasing the PRICE_BUMP_RATIO parameter from 20 to 5, the protocol can increase the price after larger cover buys but in a more gradual fashion to ensure pool managers don’t misprice risk. A more gradual price increase should improve the UX for cover buyers while serving the parameter’s intended purpose. With reasonable price changes, we should expect more consistent cover buys and less drop off due to price sensitivity.

Remove Surge Pricing from the Protocol’s Existing Price Calculations

Surge pricing was intended to increase the price during periods of high utilization to ensure the Mutual wasn’t taking on undue risk during periods of high cover volumes for a specific listing. To date, Surge Pricing hasn’t worked fully as intended. Instead, it has set a ceiling for cover buys below the 90% utilization threshold across all staking pools and made it more complicated for stakers to set pricing at rates they know customers want to transact at. Stakers often hold back capacity rather than deploying their full amount, so the surge pricing objective of charging more for the last slice of capacity doesn’t really achieve the original objective. Overall, the additional complexity of surge pricing doesn’t seem to be worth the benefit of slightly higher pricing.

If Surge Pricing were removed, the Mutual could sell more cover for the most popular listings. The Bumped Pricing change should increase more gradually and be the primary mechanism for the mutual to capture additional value during times of high cover buy volumes for a given listing. This should be sufficient to capture value without deterring potential cover buyers from purchasing more cover.

Change the Global Min Price to the Default Min Price

Currently, the Global Min Price is set to 1%. When V2 launched, the majority of the Mutual’s products were priced higher than 1% and that seemed to be a reasonable minimum price. As we near two years since V2 launched, we realised that the 1% Global Min Price doesn’t allow the Mutual to be competitive with certain product types (e.g., ETH Slashing). Staking pool managers have also indicated that certain Protocol and Bundled Protocol Cover listings could be priced lower than 1% if the pricing parameters were adjusted.

To allow for lower pricing, we would make several changes:

  • Change the Global Min Price to the Default Min Price but keep the Default Min Price at 1%.
  • Create functionality for Listing_Min_Price, which would allow the Advisory Board to configure a min price for certain listings above or below the Default Min Price
  • Create functionality for public fixed-price listings that any pool manager can stake against

These three (3) changes would allow the Advisory Board to ensure risk is not mispriced, while giving the Mutual the flexibility to offer lower pricing for battle-tested listings and for product types where pricing needs to be lower than 1% to remain competitive with other discretionary mutuals and traditional insurers. The Default Min Price would apply to any listing where the Listing_Min_Price is not specified. The Listing_Min_Price would allow the Mutual to create fixed-price public listings that ANY staking pool manager can underwrite. The minimum price would ensure a race to the bottom does not occur since dynamic pricing does not apply to fixed-price listings. Overall, these changes would improve the user experience for cover buyers and give syndicates a competitive advantage when it comes to pricing.

Specification

If approved, the Advisory Board will execute the following changes as they are ready to implement:

  • Decrease the PRICE_BUMP_RATIO parameter from 20 to 5 to reduce the rate at which a listing’s price increases after a cover buy
  • Remove Surge Pricing from the protocol’s existing price calculations
  • Change the Global Min Price to the Default Min Price
  • Create functionality to set a Min Price at the listing level, which will be called the Listing_Min_Price
  • Create functionality for public fixed-price listings that any pool manager can stake against

Proposal Status

This proposal will be open for review over the next 13 days before it moves to an onchain vote.

After this review period, the NMPIP will move to an onchain vote on Monday, 2 December.

5 Likes

Thanks @BraveNewDeFi for putting this together. I support all of the above changes. These are all smaller incremental changes based on tangible feedback from users and experience running the current pricing since the v2 launch.

3 Likes