MNX security bug bounty

Last updated: October 2, 2026

Help protect MNX and its users. We reward responsible reports of vulnerabilities in our mainnet smart contracts and the MNX-controlled systems that authorize trades, move funds, deploy production software, or determine market settlement. We pay for vulnerabilities that can lose or freeze funds or grant unauthorized production administrative or deployment access: rewards range from $5,000 to $100,000 per distinct vulnerability. Rewards are denominated in USD and paid in USDC.

Report privately to bounty@mnx.fi with the subject MNX security report. Do not publish exploit details in a GitHub issue, public chat, or social-media post.

Rewards and severity

Rewards are paid only for the impacts in this table. Denial of service, degraded availability or performance, spam, rate-limit gaps, excessive gas consumption, griefing, and other defects that cannot lose or freeze funds or grant unauthorized production administrative or deployment access are not eligible for a reward. We still want to hear about them at the address above and will acknowledge each report, but they are not paid. We may add rewards for some of these impacts later; each report is assessed under the terms published when we receive it.

Unavailability of the application, API, or relayer that lasts only while an attack continues is a disruption, not a freezing of funds, with one exception: an attack that exploits a flaw, not sheer traffic volume, to keep users from withdrawing their funds through the application and API for more than 24 hours, and that an attacker can realistically sustain for that long, is rated High as a temporary freezing of funds. Otherwise, a disruption is assessed by the lasting financial consequence it demonstrably causes, for example bad debt the liquidity vault absorbs because liquidations could not run, or funds that stay frozen after service is restored. Such a consequence is rated Critical or High under this table.

Until September 25, 2026, this policy also paid Medium rewards ($1,000–$5,000) for disruption, griefing, and excessive gas consumption, and Low rewards ($250–$1,000) for other limited-impact defects. Reports we received before this change was published are assessed under those earlier terms.

The same reward schedule applies across smart contracts, applications, and operational systems. An exploit is not capped at a lower tier because it starts off-chain. Severity follows the demonstrated consequence and actual permissions gained, not a credential's name or job title. An accounting, share-pricing, rounding, or authorization bug that steals vault principal is assessed as theft when it meets the scope and exclusions below, even if the exploit moves funds through a child account or an apparently valid redemption. Ordinary market losses are not a vulnerability.

For critical findings, the reward is the greater of $25,000 and 10% of directly affected funds, capped at $100,000. Directly affected funds are those demonstrably lost, misallocated, stealable, or permanently frozen under the deployed configuration at the time of reporting. For an incorrect settlement, count the resulting loss to affected accounts, not the full settlement volume. For insolvency, use the demonstrated unrecoverable shortfall. Include realistically repeatable exploitation; exclude hypothetical future deposits, unaffected assets, and double-counting the same collateral as both a bank balance and a vault or market balance.

Within the High range, we consider affected funds and users, how long funds stay frozen, exploit feasibility, and recovery requirements. We provide a written explanation of the classification and reward.

Paid bounties

These awards recognize reports accepted under the policy in effect when we received them. Historical awards do not change the current reward eligibility above.

This report concerned avoidable relayer gas costs. On-chain nonce checks prevented replayed changes to user funds or positions. The report was received on September 23, 2026, before Low- and Medium-severity rewards were paused.

Applications and operational systems in scope

Coverage includes the following MNX-controlled production assets and workflows. The application and API scope applies to the exact hosts listed below, not every MNX subdomain. Market-specific findings must affect a market in scope, as described in the contract scope.

• Production application: mnx.fi and app.mnx.fi, including wallet interactions, account sessions, and transaction construction.
• Production API and WebSocket service: api.app.mnx.fi, including authentication, authorization, orders, withdrawals, and account access.
• Trading, accounting, and market resolution: the MNX-controlled backend behind those services, including matching, collateral accounting, oracle publishing, settlement calculations, and resolution approval and execution for covered markets.
• Signing and privileged access: MNX-controlled production signing services, service accounts, and secret-access configuration that authorize actions on the listed services or in-scope mainnet contracts.
• Production deployment: MNX-controlled build workflows, deployment configuration, and release credentials for the mnx-markets/exchange repository where an exploit can change the listed production services or in-scope contract implementations. An unused script or development-only configuration without a production attack path does not qualify.

Bugs in MNX's configuration or integration of cloud, hosting, source-control, and identity providers are eligible when they affect these assets. Provider platforms themselves, unrelated repositories or hosts, employee devices, and personal accounts are excluded. Being in scope for reporting does not authorize access to private infrastructure; the testing rules below apply to every category.

Deployer, signer, and operator compromise

Eligible reports demonstrate a realistic way to gain unauthorized capabilities: for example, an MNX-controlled endpoint that exposes an active signing credential, an admin authentication bypass, a service-account permission escalation, or a build-workflow flaw that permits unauthorized production code or contract upgrades. Report the access path and the resulting permissions. Merely assuming possession of an owner or deployer key is insufficient.

Privileged access is critical when its demonstrated capabilities enable a critical financial impact under the deployed configuration. An unused or restricted credential is assessed by its actual impact. Researchers do not need to exercise production signing or deployment powers to establish severity; MNX can verify the permissions from safely supplied evidence.

Market resolution and settlement integrity

Eligible findings include unauthorized resolution, tampering with settlement inputs, substituting a market or outcome, reproducible payout-calculation defects, bypassing a required approval or review window, and replaying an outdated settlement instruction. Demonstrate how the resulting settlement violates the affected market's published rules or each account's entitlement. Loss of user or vault principal is assessed as a critical financial impact, whether or not the attacker profits.

Identify the affected rule, expected outcome, actual outcome, and a reproducible defect or control failure. Disagreement with a disclosed discretionary judgment, or an ordinary factual correction without such a failure, belongs in the market's published review and dispute process. Discovering a defect before settlement does not make it ineligible; reproduce the impact safely without causing a live misresolution.

Mainnet contracts in scope

This program covers the MNX shared contracts and vault accounts identified in the scope inventory, and the contracts of every market in scope, on MegaETH mainnet, chain ID 4326, including their implementations when called through their proxies. Deployed ProxyAdmin contracts that control an in-scope proxy are also covered, even if their addresses are not separately listed in the snapshot. This includes vulnerabilities in their authorization or upgrade logic, including when they use third-party library code; merely assuming possession of an administrator's key remains excluded.

Every market open for trading on MegaETH mainnet is in scope, together with its registered replacement contracts, from the moment it opens. A delisted market stays in scope until all of its positions have been closed and paid out at its settlement price. Market deployments that never opened for trading, delisted markets whose positions have all been closed and paid out, testnet deployments, unused code, and standalone third-party contracts are excluded.

The snapshot was checked on 2026-10-02 (UTC) at block 28,180,568. It records the deployed code hashes, proxy implementation addresses, and implementation code hashes of the shared contracts and vault accounts. Market contracts are in scope by the rule above and are not listed; the market registry below gives their addresses. The snapshot does not separately enumerate ProxyAdmin addresses; their coverage is defined above. This is a deployment inventory, not a security audit or a claim that the contracts contain known vulnerabilities.

Download the mainnet contract address snapshot (JSON). The linked explorer pages provide deployment and source information where available. Reproduce against the deployed implementation at a recorded block; the latest repository source may differ from deployed code.

Shared custody and authorization contracts

These contracts are priority research targets because they hold collateral or enforce permissions and calculations used across markets. The MarginBank and LiquidityVault are the primary custody and pooled-funds targets.

Vault accounts and funds

The liquidity vault is currently closed to external depositors. It has known vulnerabilities that would be exploitable if external deposits were enabled; we will fix these issues before opening the vault to external depositors. Reports that require an attacker to act as an external vault depositor are currently ineligible for a bounty.

LiquidityVault controls a main account and registered child accounts represented by SystemAccountHolder contracts. Their collateral is accounted for in MarginBank and in market positions; a token balance at the LiquidityVault address alone does not measure vault exposure. The snapshot verifies that each account below is controlled by the listed LiquidityVault.

• Main vault account: 0x134f35e00292dffaff45db8e87efe55c8082e042
• Child vault account 1: 0xbb52320a646e172aad2cbbfa9df2c09bbca59d41
• Child vault account 2: 0xb57e7b58eb4adbcc6066bb981d8ec498148950e5
• Child vault account 3: 0x172944fbaffca9ee88dac74997f915b4b8a378e8
• Child vault account 4: 0x8f385dd59ad557dfeb965fc6278a551559408545

Subject to the exclusions below, covered critical examples include unauthorized movement of vault collateral, liquidation or backstop accounting that drains vault funds, and settlement-order manipulation that pays one claimant from another's entitlement.

Market settlement and risk contracts

Each market includes Perpetual (positions and settlement), IsolatedTrader (signed trades and liquidations), IsolatedADL (automatic deleveraging), Evaluator (risk checks), FundingOracle, and its installed price oracle. The market registry gives all six addresses for every market open for trading. Oracle scope follows the installed contract, rather than assuming every market uses the same oracle type.

Discover current addresses through the public shared-contract registry, market registry, and vault registry. Registry data can lag on-chain changes: a Perpetual's addresses() function returns the oracle, funding oracle, and evaluator it currently uses.

The USDM token is an external collateral dependency. Bugs in MNX's handling of that collateral are covered; vulnerabilities solely in the token implementation, the chain, or third-party infrastructure are excluded. MNX-controlled application and operational vulnerabilities are covered by the operational scope above.

Research priorities and trust boundaries

• Unauthorized withdrawals, collateral transfers, trades, or account access.
• Exposure of active signing credentials, administrative access bypasses, and service-account privilege escalation.
• Unauthorized production builds, deployments, or contract upgrades.
• Manipulation of matching, account balances, settlement inputs, or market-resolution controls.
• Forged or replayed signatures, expired authorizations, and permission bypasses.
• Incorrect margin, funding, fees, liquidation, or automatic-deleveraging accounting.
• Vault child-account permissions and backstop exposure under the current configuration, with external deposits disabled.
• Incorrect expiry or delisting payouts, claim ordering, and failure to preserve each account's entitlement.
• Bypasses of oracle validation, freshness safeguards, risk checks, or emergency controls.

MNX uses authorized settlement operators, oracle publishers, and administrative roles. Exercising an explicitly intended power is not itself a vulnerability. Privilege escalation or bypassing a contract or operational security guarantee remains in scope. A report is not automatically excluded because a legitimate operator action is part of the reproduction. Document the required roles and distinguish normal authorized actions from an assumption that a private key was stolen.

Published smart contract audit

The Centennial Systems smart contract audit (PDF) records a June 23–July 23, 2026 engagement reviewing commit 8f4cebe4 in the exchange-contracts repository. It was a differential review of changes introduced in that commit, not a certification of every contract or the currently deployed implementations.

PDF SHA-256: b68edbf13c645b8d21d4d1dc742710bc6c4c5f25764fe73d0ea2d3a92aaa6edf. The report's closing notes state that liquidity-vault findings remained unresolved in the reviewed implementation. Historical finding statuses are not current deployment or remediation attestations. The bounty exclusion below does not imply that a finding has been fixed.

Exclusions and duplicate reports

• Findings expressly identified in the Centennial Systems smart contract audit (PDF) are known issues and are ineligible for a reward. The audit's scope alone does not exclude an otherwise novel vulnerability.
• Reports of the same underlying root cause and substantially the same security impact as an entry in our private known-issues register whose commitment was listed in the published commitments file when we received the report (for a critical report, the qualifying initial report described below). The known-issues register section below explains how a rejection is verified without disclosing other entries. An entry without a listed commitment is never grounds for a known-issue rejection.
• Vault exploits that require external depositor access. The liquidity vault is currently closed to external depositors, and known issues affecting that access will be fixed before it opens.
• Denial of service, degraded availability or performance, spam, rate-limit gaps, excessive gas consumption, and griefing, unless the report demonstrates a withdrawal block of more than 24 hours or a lasting loss or freezing of funds, as described under Rewards and severity.
• The documented public wallet portfolio endpoints are intentionally unauthenticated: /v0/users/by-eoa/:eoa_address, /v0/balance/:user_id/margin, /v0/positions/by-user/:user_id/enriched, /v0/portfolio/:user_id/realized-pnl, /v0/portfolio/:user_id/realized-pnl-periods, and /v0/portfolio/:user_id/pnl-history. Their documented public profile, margin, position, funding, fee, and profit-and-loss fields support shareable, read-only wallet portfolio pages. A report that only retrieves those documented fields without authentication is not eligible for a bounty. This exclusion does not cover credentials, contact information, authenticated-only records, fields beyond the documented response, or any unauthorized state change.
• Health endpoints, including /health/read-service-process and /health/read-service-readiness, are intentionally public. Unauthenticated access to their service names, process roles, internal port numbers, and health or readiness status is expected behavior and is not eligible for a bounty by itself. This exclusion does not cover exposure of credentials or private user data, or unauthorized actions.
• Attacks that merely assume stolen keys or credentials, without a demonstrated in-scope access path or credential-exposure failure. Safely reporting credentials exposed by an MNX-controlled system is eligible; using those credentials against production is not permitted.
• Ordinary price movements, intended trading losses, or lack of liquidity without an in-scope vulnerability.
• Incorrect third-party data alone. A flaw in MNX's validation or integration may still qualify.
• Style, gas-optimization, or best-practice suggestions without demonstrated security impact.
• Issues affecting only mocks, development environments, or unused code without a demonstrated path to covered production assets; issues solely in excluded assets.
• Reports demonstrating the same underlying root cause and substantially the same security impact as an earlier qualifying report or a publicly documented, still-applicable known issue.

We triage reports before deciding reward eligibility. When rejecting a report as known or duplicate, we identify the public finding, confirm that an earlier qualifying report exists, or send the matching register entry line, including its salt, while protecting confidential details. A materially different root cause or a new bypass of a deployed remediation is evaluated separately under this policy, including its other exclusions. An unchanged, unresolved audit finding remains ineligible for a reward.

Subject to the critical-report priority rule below, the first complete, otherwise eligible report demonstrating a distinct root cause qualifies for a reward. Multiple affected markets, contracts, services, or variants of that root cause normally form one finding; their combined impact informs the payout.

Internal known-issues register

MNX keeps a private, dated register of security issues it already knows about. We do not publish the entries. Instead we publish a commitment to each entry that can exclude a report: the SHA-256 hash of the UTF-8 line <salt>|<id>|<first-known>|<reach>|<root-cause>, with no trailing newline, where the salt is a random value chosen per entry. An entry names the affected component, the mechanism, who can trigger it, and the consequence. A report that needs a materially weaker precondition or shows a materially worse consequence is a different issue.

The commitments file lists the current hashes and a dated history of additions and removals. Those dates are our own record of when we changed the file. What decides a rejection is whether the hash was in the current list when we received the report, as shown by a copy captured before then: an Internet Archive capture of the file, or your own saved copy. Include the SHA-256 of the commitments file you consulted in your report and we will quote it in our acknowledgement. An entry whose commitment was not listed when we received a report is never grounds for a known-issue rejection. An entry leaves the current list when its fix is deployed or when we retire it to publish a corrected entry; its hash stays in the history. A bypass of a deployed remediation is assessed as a new report under this policy, including its other exclusions.

If we reject a report as a known issue, we send the matching entry line, including its salt, as a plain-text attachment. Save it as entry.txt and run tr -d '\r\n' < entry.txt | shasum -a 256 (sha256sum also works). Entry lines contain no line breaks, so the command removes any that a mail client added. The digest must appear in the current list of a copy of the commitments file captured before we received your report. This shows the entry existed before the report without revealing any other entry; whether it matches your report is a judgment you can contest with the entry in hand.

Download the known-issues commitments (JSON). 96 entries; last changed 2026-10-02.

The register is produced by automated adversarial review of our code and verified against the code by automated means. Entries are triaged and fixed by our team over time, some are accepted design trade-offs, and the list shrinks as fixes deploy. The count reflects the depth of that review, not confirmed open risk.

Report completeness and critical priority

A complete report supplies the applicable items in the submission checklist below, with enough evidence to identify and validate the vulnerability and its impact. If a checklist item does not apply, explain why. Redacted evidence and an attack path may replace steps that would require prohibited testing or handling secrets; MNX will validate those steps privately.

Report suspected critical issues immediately. A completed proof of concept is not required to preserve priority: the initial report must identify the affected asset, suspected impact, and a specific, credible attack path with enough detail to distinguish the issue. A vague claim does not reserve priority. If the issue is subsequently validated as critical and otherwise eligible, priority dates from receipt of that qualifying initial report, even if another researcher completes a report first.

The researcher must cooperate and provide reasonably requested supporting details promptly. MNX will communicate a reasonable deadline and allow extensions appropriate to the complexity and safe-testing constraints. Priority may lapse if the researcher misses that deadline without an agreed extension; delays in MNX's response or validation do not cause priority to lapse. An earlier qualifying critical report takes precedence once validated under this rule.

Safe testing and disclosure

Use local deployments, local chain forks, or an MNX-provided isolated environment for exploit reproduction. Read-only inspection of public chain data and registries is permitted. On the listed production application and API, limit testing to low-volume, non-destructive checks using accounts you control and data you are entitled to access. Do not place live exploit trades, move funds to prove impact, or change another account's state.

Do not change live prices or settlement outcomes, invoke production signing or deployment powers, run denial-of-service tests, or access private infrastructure without separate written authorization from MNX. Do not test provider platforms, phish or socially engineer staff, target personal accounts or devices, or use purchased, stolen, or exposed credentials. These limits do not exclude safely reporting a vulnerability that would expose credentials or grant unauthorized access.

If you encounter an exposed credential or private data, stop at the minimum evidence needed to report it. Provide its location, discovery steps, and redacted evidence; do not send the full secret or use it to authenticate or sign. MNX will verify validity and permissions. Do not download additional secrets or user records, or retain unnecessary copies.

To request testing beyond these limits, email bounty@mnx.fi with the target assets, proposed methods, timing, and safeguards. Wait for explicit written authorization defining the permitted activity before proceeding. Silence or acknowledgment of a report is not authorization.

Report suspected critical issues immediately; do not delay the initial notification while polishing a proof of concept. Keep exploit details private and coordinate a disclosure timeline with MNX so users can be protected before publication. We offer public credit with your permission.

Submit a report

Email bounty@mnx.fi with the subject MNX security report. Include:

1. Affected asset and environment: application or API URL, endpoint, workflow or configuration reference, or mainnet contract and implementation addresses with the fork block used, as applicable.
2. A clear description of the vulnerability and its demonstrated impact.
3. Required permissions, assumptions, attacker resources, and preconditions.
4. Reproduction steps and a runnable proof of concept in a safe environment for critical and high findings. If reproduction would require prohibited production access or handling secrets, provide redacted evidence and the attack path instead; MNX will validate the remaining steps privately.
5. An estimate of affected funds or users, with calculations and realistic repeatability.
6. Optional: the SHA-256 of /security/known-issues-hashes.json as you saw it, so a known-issue rejection can be checked against the list at submission time.
7. A contact method for private follow-up. Never include private keys or seed phrases.

Response, payment, and policy changes

We aim to acknowledge reports within 24 hours and provide an initial assessment within five business days. Critical reports receive priority. We aim to provide progress updates at least weekly while a report remains open.

For accepted findings, we aim to pay within 14 calendar days after confirming validity and the reward and completing any applicable payment requirements, which we will disclose to the researcher. Payment does not depend on public disclosure. The $100,000 maximum applies per distinct vulnerability.

MNX and this bounty program are currently in beta. Program terms, including scope, eligibility, and rewards, may change as the platform evolves. Please check the latest policy and scope before beginning research or submitting a report.