Get a demoExplore data
Token TransparencyMonad
MON ·B1 v1.4 ·1 gapPartial - 1 gap
Token

Project & Team

01

Description of Project

Provide a concise narrative that clearly states each of (a)–(e) below.

  • (a) Problem the project solves — The problem the project is solving.
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
  • (c) High-level project overview — How the project works at a high level.
  • (d) Primary token functions — The primary functions of the token (e.g. gov participation).
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

(a) Problem the project solves

General-purpose EVM blockchains face a throughput and latency ceiling that forces developers to trade off performance against Ethereum compatibility and decentralization. Monad is a high-performance, EVM-bytecode-compatible Layer-1 designed to remove that trade-off: it targets high throughput (on the order of 10,000 TPS), low latency, and sub-second finality on consumer-grade hardware, without requiring developers to abandon existing EVM tooling, languages, or contracts.

(b) Operational priorities

Core protocol research and client development are conducted by Category Labs, Inc. (formerly Monad Labs). Ecosystem development, developer documentation, governance facilitation, marketing, and related advisory activities are stewarded by Monad Foundation. Each of Category Labs and Monad Foundation expect to support ongoing development and operations from their respective treasuries.

(c) High-level project overview

Monad is a proof-of-stake Layer-1 that pairs full EVM bytecode compatibility with a re-architected execution stack, including optimistic parallel execution, pipelined (MonadBFT) consensus, deferred execution, and a purpose-built state database (MonadDb). Validators stake MON, the native token for Monad, to participate in consensus. The active set is drawn from the top stakers by weight. Each block generates a fixed inflationary block reward (currently 18 MON per block produced). The base-fee component of each transaction fee is burned.

(d) Primary token functions

MON, the native token for the Monad network, has three functions:  (i) pay transaction (gas) fees on the network, (ii) stake to secure the network and earn block rewards, and (iii) participate in validator-led protocol governance. Currently, there is no on-chain governance with the MON token, meaning that token-holders in their capacity do not have the ability to vote directly on proposals. MON confers no ownership, equity, profit-sharing, or protocol-revenue entitlement.

(e) Control surface reliance

At present, Monad Foundation facilitates validator-led governance via the Monad Improvement Proposal (MIP) process (modeled on Ethereum’s EIP process). Information regarding MIPs can be found here: https://forum.monad.xyz/c/mips/8. No governance/control evolution is anticipated.

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the:

  • (a) full names,
  • (b) official titles,
  • (c) and prior experience of key team members.

For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Labs / DevCo

Full Name

Official Title

Prior Experience

James Hunsaker

Co-Founder; CEO, Category Labs

Finance / high-frequency trading, including Goldman Sachs, J.P. Morgan, and Jump Trading

Foundation

Full Name

Official Title

Prior Experience

Petrus Basson

Director at Monad Foundation

Independent director and consultant to prominent blockchain foundations; founder of Hash Directors and co-founder of Lemma; Chartered Accountant (CA(SA)) and Certified Information Systems Auditor (CISA); former director of digital assets at KPMG

Eunice Giarta

Co-Founder; Co-GM of Monad Foundation

Software development/product management and derivatives trading

Keone Hon

Co-Founder; Director & Co-GM of Monad Foundation

High-frequency trading systems at Jump Trading

Marc Piano

Director at Monad Foundation

Independent director and consultant to prominent blockchain foundations; former counsel at Harneys

DAO / Onchain Governance

Full Name

Official Title

Prior Experience

No DAO entity or on-chain governance body exists.

N/A

N/A

03

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below.

  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
  • (f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

No DAO entity or token-voting DAO currently exists. Protocol and brand IP is held by Category Labs and Monad Foundation. Core protocol repositories are open source and accessible via Category Labs GitHub repositories

(b) Contract/admin powers

No standalone DAO legal entity or token-voting DAO currently exists. Protocol upgrades require adoption by a super majority (2/3rds) of validators by stake-weight.

(c) Locked-token rights (conditional)

Locked tokens cannot be staked. There is no on-chain governance with the MON token. Staking confers no additional rights beyond ordinary staking rewards.

(d) Current tokenholder governance rights and economic arrangements

MON holders have no contractual or protocol-enforced right to revenue distribution or to Foundation/treasury assets. Staking earns validator block rewards (18 MON per block). The base-fee component of transaction fees is burned. No dividend, buyback, or revenue-share to holders exists or has been formally adopted. At present, Monad Foundation facilitates validator-led governance via the Monad Improvement Proposal (MIP) process (modeled on Ethereum’s EIP process). There is no on-chain governance with the MON token, meaning that token-holders in their capacity do not have the ability to vote directly on proposals. MON confers no ownership, equity, profit-sharing, or protocol-revenue entitlement. Information regarding MIPs can be found here: https://forum.monad.xyz/c/mips/8.

(e) Control surface reliance

No DAO entity or on-chain governance body exists or is anticipated, and there is currently no on-chain governance with the MON token, nor is one currently anticipated. Token-holders do not have the ability to vote directly on proposals in their capacity as token-holders. Protocol governance is exercised by validators through client-software adoption by a supermajority of 2/3rds of validators by stake-weight, and protocol upgrades require adoption by that same supermajority threshold. The protocol’s governance/control model may evolve through the governance/MIP process, including changes to protocol parameters such as the block-reward rate, fee/burn mechanics, and incentive or delegation programs; such changes could increase or decrease effective inflation, alter reward distribution, or otherwise materially impact tokenholders.

(f) Dissolution authority

There is no DAO to wind up.

04

Primary Foundation

For the Primary Foundation do the following independently. If a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary Foundation can be explained as the entity which is directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities, and the method/threshold for each (e.g., veto/majority/super-majority).
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly.

(a) Entity

Monad Foundation is a Cayman Islands foundation company.

(b) IP ownership & control

The Foundation holds rights to, and stewards, the Monad brand and associated trademarks and certain protocol-related materials (e.g., developer documentation, monad.xyz and developer documentation). Protocol-related materials are generally hosted in a GitHub repository and made available under open source software licenses.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No DAO entity or token-voting DAO currently exists. The Ecosystem Development allocation consists of tokens allocated to and administered by the Foundation to support ecosystem development and related Foundation purposes. Decisions regarding the use of this allocation are made pursuant to the Foundation’s ordinary corporate governance and delegated-authority framework. Deployments are approved by a majority of the board of directors entitled to vote on it, although in practice are customarily approved by the entire board of directors. Immaterial ordinary course spend may be delegated to individual team members by the board of directors on a case-by-case basis. The Foundation does not have any powers over protocol-controlled resources such as revenue, token administration, or reward parameters.

(d) Powers over DevCo

Monad Foundation and Category Labs are unaffiliated. Monad Foundation holds no equity in, board seats on or other authority over Category Labs and cannot direct Category Labs decision-making. The Monad Foundation compensates Category Labs for certain development and technical services on an arm’s-length basis.

(e) Contract/admin powers

Monad Foundation does not have pause, upgrade or governance-executor authorities over the protocol. Any upgrades of the protocol require a super majority (2/3rds) of validators by stake-weight.

(f) Current economic arrangements and distribution policies

There is no current governance-approved, contractual, or programmatic mechanism by which protocol fees, protocol revenue or other protocol-controlled resources are automatically directed to the Foundation, any equityholder, or Foundation contributors. The Foundation is a memberless Cayman foundation company and does not have equityholders.

The Foundation holds the Ecosystem Development allocation from Q6 and other assets in its treasury and may deploy or distribute those assets in furtherance of its mission, including through ecosystem grants, incentive programs, validator delegations and other ecosystem-development activities, subject to the Foundation’s applicable governance and delegated-authority processes as described in Q4c above.

When the Foundation delegates MON via the Validator Delegation Program, it receives staking rewards attributable to its stake in accordance with the terms of the program and the protocol’s generally applicable rules.

Foundation contributors receive Team tokens on the Q6 schedule. The Foundation pays Category Labs for services.

There is no other current mechanism pursuant to which protocol-controlled assets, fees, revenue or rewards are specially allocated or directed to Foundation contributors or other insiders.

05

Primary DevCo

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary DevCo can be explained as the entity which is directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Category Labs is a Delaware corporation.

(b) IP ownership & control

Category Labs develops and holds the core protocol and client IP. Core protocol repositories are open source and accessible via Category Labs GitHub repositories. Category Labs holds rights to the Category brand and associated trademarks.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No DAO entity or token-voting DAO currently exists. Category Labs has no protocol-controlled resource, token-administration or reward parameter authority. It holds a 3.95% Category Labs Treasury allocation, over which it has complete discretion.

(d) Powers over Foundation

Monad Foundation and Category Labs are unaffiliated. Category Labs cannot exert direct or indirect influence over the decision making of Monad Foundation. Category Labs provides development and technical services in respect of the Monad core protocol for which Monad Foundation compensates Category Labs on an arm’s-length basis.

(e) Contract/admin powers

Category Labs does not have pause, upgrade or governance-executor authority over the protocol. Any upgrades of the protocol require a super majority (2/3rds) of validators by stake-weight.

(f) Current economic arrangements and distribution policies

There are no governance-approved, contractual, or programmatic mechanisms by which protocol-controlled resources, fees, revenue, rewards, or token distributions are specially directed to Category Labs, its equityholders, contributors, or other participants. Investors in Category Labs received Investor tokens under token warrants per Q6. Category Labs contributors receive Team and Treasury tokens per Q6. The Foundation pays Category Labs for services out of Foundation treasury assets.

Token Supply & Allocations

06

Initial Allocation

Ticker

Date

Allocation Category Name

Recipient Type

Allocation %

Allocation Tokens

TGE Unlock %

TGE Unlock Tokens

Cliff Months

Cliff Unlock %

Linear Vesting Months

Cadence Months

Circulating Treatment

Notes on what each category is used for

If applicable: Contract / Wallet address

MON

11/24/25

Ecosystem Development

Ecosystem

0.38544142854

38544142854

1

38544142854

0

0

0

0

No

Unlocked; stewarded by Monad Foundation for ecosystem growth opportunities and initiatives. Foundation-held and excluded from circulating until deployed.

MON

11/24/25

Team

Insiders

0.26989187887

26989187887

0

0

12

0.396

36

0

No

Foundation & Category Labs founders/employees/contractors. Locked 1 year; then released over the following 3 years (individual schedules typically 3 to 4 years). ~10.7% of initial total supply released by the 1-year anniversary of mainnet launch. Note that it is not strictly linear due to individual vesting schedules tied to initial start dates of team members.

MON

11/24/25

Investors

Private / VC

0.19647582746

19647582746

0

0

12

0.25

36

1

No

Category Labs fundraising investors. 4-year lock-up with 1-year cliff followed by equal (1/48) monthly unlocks thereafter.

MON

11/24/25

Public Sale

Public / Sale

0.075

7500000000

1

7500000000

0

0

0

0

Yes

Sold to the public via Coinbase token sales platform at $0.025/MON; 100% unlocked at launch.

MON

11/24/25

Category Labs Treasury

Treasury

0.03988503117

3988503117

0

0

12

0.25

36

1

No

Future employee compensation. 4-year lock-up with 1-year cliff followed by 1/48 monthly thereafter.

MON

11/24/25

Airdrop

Community

0.03330583396

3330583396

1

3330583396

0

0

0

0

Yes

Community + wider crypto community; unlocked at claim. See Airdrop Process below.

Note 1: The initial allocations between Investors and Category Labs Treasury reflect a net adjustment of 37 million MON from the initial tokenomics resulting from administrative adjustments.

Note 2: The Category Labs Treasury allocation excludes any MON acquired through open-market purchases pursuant to Category Labs’ previously announced token purchase program.

07

Airdrop Process

State the project's airdrop status plainly, and back it up:

  • Never conducted and none planned for TGE: state so plainly.
  • Planned but not yet executed: state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed.
  • Already executed: state the covered user segments and the allocation method, and point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count.

Launch Airdrop

The launch airdrop occurred coincident with Monad mainnet on November 24, 2025, after an October 1, 2025 snapshot and a claim window that closed on November 3, 2025. The airdrop covered five categories spanning the Monad community and the wider crypto community, with Sybil filtering applied. Approximately 3.3 billion MON, or 3.3% of initial supply, was claimed by roughly 76,021 wallets. A CSV of claimed MON amounts by wallet is available for download here: https://raw.githubusercontent.com/monad-crypto/airdrop-addresses/refs/heads/main/monad_airdrop_results.csv.

Accounts qualified for eligibility in five different tracks, each with a number of subtracks. Accounts that qualified through multiple subtracks were eligible to receive the combined total of their subtrack allocations. These tracks include:

  • Monad Community
  • Onchain Users
  • Crypto Community
  • Monad Builders
  • Crypto Contributors and Crypto Curious

The allocation method used to calculate per-recipient amounts is here: https://monad.xyz/blog/the-mon-airdrop-results

Claimer Wallets

In total, 76,021 unique wallets claimed MON tokens. A CSV of claimed MON amounts by wallet is available for download here.

All claimer wallet addresses were checked against the latest sanctions designations listed on economic/trade embargo lists from organizations including the US, EU, or UN. This check was performed using the Chainalysis oracle for sanctions screening. In addition, the claim portal (https://claim.monad.xyz/) geo-blocked users from the following jurisdictions: Cuba, Iran, North Korea, Syria, Sevastopol, Crimea, Donetsk, and Luhansk.

We also actively excluded team members from participating in the airdrop by disqualifying identifiers associated with project team members from the list of eligible recipients. In addition, the Monad Foundation and Category Labs implemented policies expressly prohibiting full-time team members from claiming tokens in the Monad airdrop.

Monad Community

The Monad Community was the largest track in the MON airdrop. 5,935 accounts were allocated 1.670B tokens, of which 1.665B tokens (99.7%) were claimed.

The Monad Community airdrop was allocated using an intensive process based pm the past impact of each community member through a comprehensive and multi-faceted analysis featuring significant input from the community itself.

Impactful, long-term community members were identified using data from social media platforms including Discord, Telegram, and X. We built an interface for community members to provide input on who else they would consider a community member. The Monad Community team also spent several months providing manual input. After the claim portal went live with a claim strength indicator, we ran a vouching system where community members could identify people we missed.

Onchain Users

The Onchain Users track was the second-largest in the MON airdrop. 229,433 accounts were allocated 1.705B tokens, of which 699M tokens (41.0%) were claimed. 

This track generally consists of power DeFi users and longtime NFT holders. DeFi subtracks were based on usage of Hyperliquid, Pump.fun, Aave, Euler, Uniswap, OpenSea, Pendle, Phantom, Morpho, Lighter, Virtuals, Backpack, and other onchain activity. NFT subtracks were based on the following collections: Mad Lads, CryptoPunks, Moonbirds, Milady Maker, Sappy Seals, Meebits, Doodles, Hypurr/other Hyperliquid NFTs, Monad Testnet Purple Pass, Pudgy Penguins, Fluffle, Azuki, Redacted Remillio Babies, Solna Monkey Business (Gen 2) and other NFT collections.

Crypto Community

The Crypto Community track was the third-largest in the MON airdrop. 46,017 accounts were allocated 897M tokens, of which 635M tokens (70.8%) were claimed.

Note that Monad Cards Wave 1 recipients received 88,888 MON, Monad Cards Wave 2 recipients received 38,888 MON, and Monad Cards recipients who failed to claim their cards received 18,888 MON.

Subtracks consisted Monad Cards, Legion Investors, Echo Investors, Monad Event Attendees, LobsterDAO, Farcaster Users [ ] Community, ARC Community and other crypto communities.

Monad Builders

The Builders track was the fourth-largest in the MON airdrop. 2,860 accounts were allocated 288M tokens, of which 225M tokens (78.4%) were claimed.

The Builders track consisted of team members of Monad-native projects (noted in the table below as Monad Native Builders), as well as developers participating in developer challenges such as Monad Blitzes and Monad Missions (noted as Other Builders).

Crypto Contributors and Crypto Curious

This track was the fifth-largest in the airdrop and included both the Public Goods and Education subtracks. 4,431 accounts were allocated 172M tokens, of which 107M tokens (62.1%) were claimed.

The Public Goods subtrack consisted of Cantina auditors, Protocol Guild members, SEAL 911 members, and ZachXBT. The Education subtrack consisted of RareSkills students and staff, SheFi students and staff, and current members of select university blockchain clubs.

Post-Launch Serendipity Airdrops

Between March and May 2026, Monad Foundation made three MON distributions to addresses on the Monad network. There was no claim step meaning that MON went straight to each recipient address. Team wallets were excluded, and all wallets were checked against the latest sanctions designations listed on economic/trade embargo lists from organizations including the US, EU, or UN. A CSV of claimed MON amounts by wallet is available for download here: https://github.com/monad-crypto/airdrop-addresses/tree/main/serendipity-drops

  • Distribution 1 (March 30, 2026): active onchain NFT holders. 1,995 addresses, 8,000,000 MON. The airdrop covered addresses that held at least one NFT from a defined set of 21 PFP collections at the March 23, 2026 snapshot and had spent at least 1 MON in gas on Monad between January 1, 2026 and the snapshot.
  • Distribution 2 (April 13, 2026): general onchain users. 4,908 addresses, 9,000,000 MON. The airdrop covered addresses that based on gas spend transactions on Monad other than ERC-20 token transfers between March 12, 2026 and the April 11, 2026 snapshot and passed anti-sybil filters.
  • Distribution 3 (May 5, 2026): general DEX users. 3,570 addresses, 10,000,000 MON. The airdrop covered addresses that with over $2500 in weighted volume among Uniswap, Pancakeswap, LFJ, Kuru, Perpl, LeverUp, and Nad.fun on Monad between April 1, 2026 and May 1, 2026.

Allocations were set retroactively from onchain activity in each window. It excluded addresses that were active on all 30 days of the window, addresses that averaged more than 50 transactions a day, and addresses that interacted with fewer than two non-spam contracts. A spam contract was one where the top 10 addresses made over 99.9% of its transactions.

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly. For each market maker, include in a table:

  • (a) Market maker's name — the market maker's name;
  • (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
  • (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
  • (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model).

If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).

Market Maker Name

Token Allocation Committed

Term Duration

Structure Name

Wintermute

0.02% of supply

One year from launch

Loan

GSR

0.03% of supply

Month-to-month

Option

Sellini

0.02% of supply

Month-to-month

Retainer

09

Exchange Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:

  • (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
  • (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
  • (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
  • (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.

If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Exchange Name

Token Allocation Committed

Term Duration

Native Token Listing Fees

Bitget

0.05% of supply committed for marketing

Until completed; no specified end date

N/A

Bybit

0.03% of supply committed for marketing

Until completed; no specified end date

N/A

OKX

0.20% of supply committed for marketing

Until completed; no specified end date

N/A

Revolut

0.10% of supply committed for learn & earn

12 months

N/A

Unnamed Exchange

<0.05% of supply committed for marketing

Until completed; no specified end date

N/A

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:

  • (a) Series Name;
  • (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.);
  • (c) Date of sale (at least month & year);
  • (d) Number of tokens sold (or % of total supply);
  • (e) Vesting schedule.

If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

Series Name

Investment Instrument

Date Of Sale

Number of tokens sold

Vesting Schedule

Pre-Seed

Equity + Token Warrants

Dec. 2022

8,358,666,713 tokens (8.4% of initial supply)

4-year lock-up, 1-year cliff, 1/48th monthly thereafter

Seed

Equity + Token Warrants

Mar. 2024

2,897,406,707 tokens (2.9% of initial supply)

4-year lock-up, 1-year cliff, 1/48th monthly thereafter

Series A

Equity + Token Warrant

Apr.-Aug. 2024

8,391,509,326 tokens (8.4% of initial supply)

4-year lock-up, 1-year cliff, 1/48th monthly thereafter

Public Sale (Coinbase)

Token Sale through Coinbase Token Sales platform

Nov 2025

7.5B tokens (7.5% of initial supply)

100% unlocked at mainnet launch

11

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
  • (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
  • (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
  • (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
  • (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
  • (f) References — Link(s) to post-mortem/advisory/PR.

(a) Date & component affected

No exploits affecting the MON token or the Monad network have occurred as of 2026-09-24; accordingly, there are no incident dates or affected token components to disclose.

(b) Exploit vector summary

No exploit vector is disclosed because no exploits affecting the MON token or the Monad network have occurred as of September 24, 2026.

(c) Quantified impact

No quantified impact: no exploits affecting the MON token or the Monad network have occurred as of September 24, 2026.

(d) Remediation/response taken

No remediation or response for prior exploits is disclosed because no exploits affecting the MON token or the Monad network have occurred as of September 24, 2026.

(e) Current status

No exploits affecting the MON token or the Monad network have occurred as of September 24, 2026; accordingly, there is no incident status to report.

(f) References

No post-mortem, advisory, or PR references are applicable: no exploits affecting the MON token or the Monad network have occurred as of September 24, 2026.

12

Material Risk Factors (Regulation, Technology, Token Economics)

Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.

  • (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:

  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?

  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?

  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?

  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?

  • (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:

  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?

  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?

  • (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:

  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?

  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

(a) Regulatory, Legal & Tax Risks

Impact of regulatory change on MON distribution and listings. The initial public distribution of MON was completed at the mainnet launch on November 24, 2025. Evolving or conflicting laws across key jurisdictions could nonetheless affect the ability of trading venues to support MON, restrict access for users in certain regions, or impose registration or licensing requirements on the token or the teams supporting Monad.

Entity-level regulatory impact. Regulatory or legal change could affect Monad Foundation, Category Labs, and affiliated service providers through enforcement action, new licensing or registration requirements, or forced changes to structure or operations. Shifts in applicable AML/KYC requirements, sanctions regimes, or crypto-specific regulations could require restructuring of operations, entity dissolution, or relocation of the legal domiciles.

Tokenholder tax treatment. The tax treatment of holding, staking, receiving airdropped, or transacting in MON varies by jurisdiction and over time. Tokenholders are solely responsible for understanding and meeting their own tax obligations. Nothing in this report is tax advice.

Jurisdictional & user-access restrictions. The Monad network is permissionless and accessible to any user with a compatible wallet. However, certain front-end interfaces or platforms in the Monad ecosystem may implement geo-restrictions, including restrictions for users in sanctioned countries. Access to the public sale and airdrop was restricted for sanctioned jurisdictions/persons.

(b) Protocol, Technology & Security Risks

Bugs and design flaws. Monad relies on novel systems (e.g., MonadBFT consensus, optimistic parallel execution, and MonadDb) as well as third-party bridges and oracles. Bugs, design flaws, or implementation errors in the protocol, smart contracts, or these dependencies could cause loss of funds, incorrect state, or disruption of the network.

Security measures & limitations. Mitigations include third-party audits, formal verification of critical components, and a bug-bounty program. These measures reduce but cannot eliminate risk; novel or composite failure modes may not be detected or prevented.

Novel architecture. Monad introduces several components that are new and have limited production history at scale, including optimistic parallel execution, the pipelined MonadBFT consensus protocol, deferred execution, and the MonadDb state database. Systems of this novelty may exhibit failure modes, performance characteristics, or edge-case behaviors that are not present in more mature blockchains and that auditing, formal verification, and testnet operation may not surface until they manifest under mainnet conditions or adversarial load.

Slashing. The protocol contemplates slashing as an accountability mechanism for malicious, slashable offenses, but automated in-protocol slashing is not currently implemented. Until it is, deterrence of validator misbehavior relies on protocol logging and off-protocol responses rather than automatic economic penalties, which may reduce the immediacy of consequences for certain adversarial validator behavior. If and when automated slashing is introduced, stakers and delegators would additionally bear the risk of losing a portion of staked MON due to validator faults or downtime.

Dependence on third-party infrastructure. Users and applications on Monad depend on infrastructure outside the protocol's control, including cross-chain bridges, price oracles, RPC and indexing providers, wallet software, front-end interfaces, and third-party stablecoin issuers. A failure, exploit, or discontinuation of any such dependency could result in loss of user funds or disruption of applications even if the Monad protocol itself operates correctly.

(c) Token Economics, Unlocks & Incentive Risks

Critical economic assumptions. Network security, utility, and governance depend on assumptions including sufficient staking participation and yields, transaction-fee revenue and demand for blockspace. If these assumptions fail, for example, if staking participation or fee revenue is lower than expected, network security incentives and token utility could be adversely affected.

Governance control over monetary policy & rewards. Protocol parameters, including the block-reward rate, fee/burn mechanics, and incentive or delegation programs, may be changed through the governance/MIP process. Such changes could increase or decrease effective inflation, alter reward distribution, or otherwise materially impact tokenholders.

Scheduled unlocks. Approximately 50.6% of initial supply (Team, Investors, Category Labs Treasury) was locked at launch and unlocks over time, with full unlock of initial-supply locked tokens anticipated by Q4 2029. Scheduled unlocks increase circulating supply and may create sell-pressure and price-volatility risk for holders.

This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Monad is solely responsible for the content, accuracy, and legality of its disclosures.

The daily brief, in your inbox

Markets, protocols, and policy, read by 200K+ professionals.

Blockworks Inc.133 W 19th St., New York, NY 10011

Solutions

InvestorsExchangesEnterprisesOnchain Businesses

© 2026 Blockworks Inc.

TermsPrivacy PolicyPrivacy CenterNews Archive