Project & Team
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.
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 |
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.
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.
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
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. |
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
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 |
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
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 |
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.
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.