NXM is a membership-gated balance-sheet token, not a free-floating governance chip

Nexus Mutual is an onchain discretionary mutual. The core product is “cover” on crypto risks. The token, NXM, is the internal accounting unit that ties members to the mutual’s capital base and to its political machinery. The protocol’s documentation frames it plainly: NXM is backed by the assets in the Capital Pool and is used for underwriting, governance participation, and claims-related roles.

The first power move is constituency design. To interact as a member, you go through KYC/AML and pay a 0.0020 ETH membership fee. If you fail KYC, you do not join. That restriction is not cosmetic. It hard-bounds who can hold native NXM, who can vote with native NXM, and who can realistically participate in claims and underwriting in the native system.

That gating is also embedded at the token contract level. The NXM token contract includes a whitelist requirement on transfers via a canTransfer modifier. In other words, “tokenholder” is not the same thing as “any Ethereum address.” It is “addresses the system recognizes as members.”

NXM’s functional roles line up with the mutual’s operations:

1) It opens underwriting capacity when staked into staking pools, with reward mechanics defined in the staking system design.

2) It expresses voting power in governance.

3) It is part of the claims assessment incentive and fraud enforcement machinery, including burn-based penalties for fraudulent behavior.

Wrapped NXM (wNXM) exists as the “DeFi-composable” proxy, but it sits outside the mutual’s native rights system and membership-bound permissioning.

Supply is elastic. Emissions are operational. The cap is political.

NXM does not behave like a fixed-supply asset with a predetermined unlock calendar. Supply expands and contracts as part of the mutual’s capital management. If you’re contrasting elastic supply with fixed-supply governance tokens, the difference here is that issuance is entangled with ongoing operations.

The current onchain total supply (what some trackers label as a “max total supply” field on the token tracker UI) is about 1,858,970.93 NXM.

Some market-data aggregators also describe NXM with an effectively unbounded max supply, which is consistent with an elastic model where minting can occur under protocol rules rather than a hard cap.

The important part is not the “infinite” label. It is who can cause minting and under what triggers:

1) Member-driven mint/redeem via the RAMM. The token model describes two internal pools. In the Above Pool, ETH comes in and NXM is minted. In the Below Pool, NXM is redeemed for ETH and the redeemed NXM is burned.

2) Staking rewards minted from premium flow. When cover is purchased, 50% of the cover fee is minted as NXM rewards and streamed to the stakers in the relevant pool over the cover period. That is a real, ongoing inflation channel tied to business volume.

3) Privileged mint/burn paths exist at the token-controller layer. The token contract itself exposes minting gated by operator permissions, and the system architecture places minting and burning behind a controller/operator flow. This is normal for protocol-controlled tokens, but it means “supply policy” is ultimately “governance + admin key policy,” not immutable issuance math.

If you are looking for a clean “allocation pie chart,” current primary docs do not provide one in a way that is structurally safe to model as a binding commitment. That absence matters. For a general framework to evaluate these tradeoffs, see our token design principles.

Fiscal flows: premiums strengthen the pool, while NXM inflation pays underwriters

NXM’s economics are easiest to read as a mutual balance sheet with two linked ledgers: the Capital Pool assets, and the NXM supply that represents member ownership claims on that pool.

Premium inflow: Cover fees are paid into the Capital Pool in full. The documentation is explicit that cover fees flow into the pool and claims are paid from it.

Underwriting incentives: In parallel, the staking system mints NXM rewards equal to 50% of the cover fee and streams them to the staking pool underwriting that cover. This is not a “revenue share” paid from the pool. It is inflation funded by the protocol. It compensates stakers for taking first-loss exposure on claims.

What the other 50% does: The FAQ frames risk sharing in a way that implies the remaining portion of the fee accrues to the capital backing NXM and therefore benefits all NXM holders. It also explains the claim-loss sharing structure (more on that below).

Claims outflow and who eats losses: Claims are paid from the Capital Pool in the asset terms of the cover.

The same FAQ also states a key structural property: because 1 NXM opens 2 NXM worth of capacity, when claims are paid, 50% of a claim is paid via burning NXM staked to underwrite the cover and 50% is socialized across all NXM holders. That is the mutual’s loss mutualization rule, expressed in token mechanics.

This is the real “tokenomics engine.” Premiums expand the pool. Underwriting is paid in inflation. Losses hit stakers directly through burns and hit all holders indirectly via a reduced pool backing per token.

Cover itself is tokenized. After purchase, cover is represented as an ERC-721 NFT. It can be transferred to a non-member address, even though buying cover and filing claims is tied to membership flows. That design enables distribution partners to route cover in ways that do not perfectly map to “end user = member” at the moment of purchase, while still pulling claims into the membership/KYC perimeter.

Capitalization controls: RAMM pricing hugs book value, and MCR throttles exits

NXM’s pricing and liquidity are not “let the market clear.” They are a managed interface between members and the mutual’s capital base.

The current model is the RAMM token model. It is a two-pool internal market built on top of the Capital Pool. Its purpose is to let members mint and redeem NXM while keeping the system solvent for large loss events.

The mechanics are book-value anchored:

Book Value (BV) is defined as Capital Pool value in ETH / NXM supply.

Redemptions happen “below BV” in the Below Pool, where redeemed NXM is burned. Minting happens “above BV” in the Above Pool, where incoming ETH mints NXM. The ratchet mechanism moves internal prices back toward BV over time, creating a controlled spread and limiting reflexive death spirals.

The solvency governor is the Minimum Capital Requirement (MCR). Nexus Mutual defines MCR as the minimum funds needed to be very confident it can pay all claims. The current onchain formula is:

MCR = Total Active Cover Amount / 4.8.

That “4.8” is not sacred math. It is a gearing factor that the docs explicitly describe as something that can be updated via governance if the off-chain capital model diverges materially.

MCR also gates liquidity injection into the RAMM. The Token Model page states the protocol will not add liquidity to the RAMM pools if the Capital Pool ETH balance is less than or equal to MCR + target liquidity. In shorthand: redemptions are throttled by solvency constraints.

The RAMM has explicit parameters that matter for exit liquidity and price behavior. Members signaled support for a target liquidity of 5,000 ETH, and the docs list long-term controls including a 1% oracle buffer, and 100 ETH daily max liquidity move speeds in and out of the pools in long-term state.

The 2023 token model upgrade is relevant history because it was explicitly framed as solving the “MCR lock problem,” where redemptions were constrained. Nexus Mutual’s own post states that on November 21, 2023, the Bonding Curve was replaced with the RAMM and the MCR floor was removed following approval of NMPIP-209. It also disclosed launch-state RAMM parameters including an initial budget of 43,835 ETH and a 1,500 ETH/day max liquidity injection rate during the initial state, later dropping to 100 ETH/day in long-term state.

From a governance power lens, the RAMM is a trade. It gives the system a controlled exit route. It also makes liquidity policy an explicit parameter set. Those parameters are therefore political objects.

Governance power map: the optimistic model concentrates agenda control

Nexus Mutual’s governance docs describe an optimistic governance model. The Advisory Board (AB) creates a proposal and sets the default outcome. Members vote to reject the default outcome on Snapshot. If rejection meets quorum, the proposal dies. If it does not, the AB’s default stands.

The key parameter here is the rejection threshold. The docs state that to defeat a proposal, members must vote with at least 15% of the NXM token supply to deny the AB’s default outcome.

That is a high bar in practice for any system with voter apathy and a membership-gated electorate. It structurally shifts power toward whoever controls proposal routing, framing, and default positioning. For a different governance-and-reserve design, compare this with our Reserve Rights review.

Voting power is described as: one vote per member plus the sum total of their NXM tokens.

There are also explicit timelines. Governance votes run for 3 days with a 24-hour timelock after the vote closes.

The Advisory Board has “power in limited circumstances,” but those circumstances are exactly the ones that matter when things go wrong. The governance docs state the AB can take emergency action to pause the protocol and can perform technical upgrades when granted authority by members. It also notes an Emergency Pause Safe multisig whose only power is pausing the RAMM contract or the entire protocol.

Even if you accept the “limited” framing, it is still concentrated power. Pausing the protocol is a nuclear option that changes everyone’s liquidity and operational rights instantly.

Now look at delegation and managerial capture risk. In the updated staking model, passive stakers delegate both capital and voting power to staking pool managers. Managers can use delegated voting power in onchain governance. Delegated stakes cannot be used for claims assessment, but they can be used politically.

This design is operationally efficient. It reduces coordination costs. It also builds “proto-delegates” into the system. Pool managers become political intermediaries. Over time, that can concentrate governance into a smaller set of professional operators, even if NXM ownership is broadly distributed.

Claims governance is even more centralized than the marketing copy suggests. The protocol docs describe the claim assessment process as involving a Claims Committee that reviews submissions and votes, currently listed as three individuals. The docs state that claims are open for voting for at least 72 hours, and that at least 2 of the 3 Claims Committee assessors must cast accept votes for a claim to be accepted.

There is also a 24-hour cool-down period after claim voting closes, explicitly to allow the Advisory Board to determine if fraud occurred and to reverse fraudulent votes and replace assessors.

On the contract side, the Assessment module includes a fraud resolution process that can burn tokens from fraudulent assessors via processFraud with Merkle proof verification. That is a hard enforcement mechanism. It is also a governance surface because “fraud identification” is not purely mechanical in adversarial, high-stakes incidents.

One more technical detail matters for whale dynamics. Some proposal types cap voting power at 5% of total supply per address at the time of voting, alongside additional quorums and timelocks for AB-related proposal types in certain implementations. That cap reduces single-address dominance. It does not remove coalition dominance, and it does not address pool-manager aggregation unless the system enforces caps at the aggregation layer.

Risk register: where NXM’s design strains

The protocol has real strengths. The token model anchors to book value, ties liquidity to solvency, and routes underwriting incentives to the participants who take first-loss exposure. The weaknesses are mostly political and reflexive. They show up when you assume stress, low participation, or contested claims. For more work like this, browse our research reports.

Top 3 risks

  1. Governance capture via optimistic defaults (dominant risk). Trigger: low turnout on contentious parameter changes or emergency actions during a volatile market or major exploit cycle. Mechanism: the Advisory Board sets the default outcome and members must mobilize 15% of supply to reject within a 3-day window, with a 24-hour timelock afterward; pool managers can vote with delegated power, compressing “who actually decides.” Who bears it: all NXM holders (dilution policy, liquidity policy, investment allocations), stakers (burn exposure and reward policy), and cover buyers (claim rules and product scope). Measurable indicators: falling % of supply participating in Snapshot votes, rising concentration of delegated stake in a few pools, and repeated proposals passing with minimal rejection voting.

    Why this dominates: Nexus Mutual is not “just” a token with governance. It is a balance sheet plus an adjudication system. That means governance changes can be equivalent to rewriting solvency policy, liquidity policy, and claims policy. The RAMM itself is parameterized. Target liquidity, ratchet speeds, oracle buffer, and liquidity injection limits determine whether members can exit near book value, and how quickly. Those are not neutral parameters. They distribute pain between exiting members and remaining members, and between short-term and long-term holders.

    The same is true for MCR. With MCR = Active Cover / 4.8, the gearing factor becomes a governance lever over how much capital must stay in reserve versus how much can be made available for liquidity operations. In practice, that is a lever over redemption capacity and over the mutual’s ability to take on more cover. Changing it changes both growth and safety.

    Then there is agenda control. The AB authors proposals and sets defaults. Even if members can replace AB members through onchain proposals, the replacement process itself requires minimum thresholds, including that the proposer hold at least 100 NXM and that 15% of supply participate in the vote. That is a meaningful friction layer against rapid political change by small holders.

    In stress, this governance design tends to centralize further. Emergency pause powers exist, including a dedicated multisig with pause authority over the RAMM or the full protocol. Pausing is sometimes necessary. It also moves power from tokenholders to signers at exactly the moment when markets are repricing risk and when liquidity is most valuable.

    The claim system adds another layer. The protocol’s Claim Assessment documentation describes a three-person Claims Committee and a 2-of-3 accept requirement. That is explicit human adjudication, not purely “community voting.” It may improve decision quality. It also centralizes the claims outcome pipeline, and therefore the capital outflow pipeline. In a large loss event, claims policy becomes macro policy.

    The net is simple: Nexus Mutual’s decentralization is better described as “member legitimacy + veto option” than “diffuse control.” Operational flexibility is bought with governance centralization. That can be the correct trade. It is still the trade.

  2. Exit liquidity risk during drawdowns and high claim probability. Trigger: a spike in expected claims, rapid growth in active cover (raising MCR), or capital pool drawdowns due to paid claims or investment losses. Mechanism: RAMM liquidity injection is constrained by solvency; the system will not add liquidity if Capital Pool ETH is not above MCR + target liquidity, and redemptions burn NXM for ETH below book value ranges. Who bears it: NXM holders attempting to exit through native redemption, and any holders relying on RAMM as a book-value-ish exit. Measurable indicators: MCR rising relative to Capital Pool, falling RAMM liquidity vs target, widening gap between internal pricing and external wNXM pricing, and increased redemption throttling as described by MCR constraints.

  3. Underwriter dilution and burn concentration. Trigger: cover sales surge without proportional growth in informed underwriting, or a claim event hits a concentrated set of pools/products. Mechanism: staking rewards are paid via inflation equal to 50% of cover fees, while claim payouts can burn staked NXM allocated to the affected products; delegated stakers can be exposed to burns while not controlling pool allocations directly. Who bears it: stakers in the affected pools first, then all NXM holders via reduced backing and continuing inflation. Measurable indicators: accelerating NXM rewards minting relative to Capital Pool growth, higher burn incidence per pool, and persistent underpricing of risk reflected by repeated burns on similar product clusters.

If you are doing tokenomics consulting or token economy design work around NXM exposure, treat governance and liquidity parameters as first-class variables. The “model” is not just premiums and claims. It is who can change the rules, how hard it is to coordinate vetoes, and how delegation concentrates effective control.



This article is part of our Tokenomics Deep Dive series.