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
Meteora addresses liquidity fragmentation and inefficient price discovery in DeFi. Traditional AMMs struggle with capital inefficiency, poor execution for altcoins, and suboptimal liquidity bootstrapping for new token launches. Meteora's core thesis is that the existing AMM infrastructure doesn't adequately serve the token experimentation and issuance needs of the crypto ecosystem, leading to poor LP returns, volatile launches, and limited pathways for tokens to mature into legitimate, tradeable assets.
(b) Operational priorities
Meteora sustains development and operations through protocol-generated revenue. The project generated ~$120M in revenues in 2025 from trading fees across its AMMs and launchpads. The team operates with strong treasury management and consistent financial reporting. The 34% "Meteora Reserve" allocation (vesting over 60 months post-cliff) provides a runway for ecosystem growth. Meteora has not raised capital to date and operates with a philosophy that all surplus value accrues to users/stakeholders rather than to separate labs or equity entities.
(c) High-level project overview
Meteora is a Solana-native liquidity infrastructure stack mainly comprising:
i. DLMM (Dynamic Liquidity Market Maker)
discrete bins with dynamic fees for concentrated liquidity
- ii. DAMM v1/v2 (Dynamic Automated Market Maker) – constant-product AMMs optimized for different use cases
- iii. DBC (Dynamic Bonding Curve) – bonding curves for token launches
(d) Primary token functions
We plan to eventually enable staking for the $MET tokens, and to pilot a $MET Economy that revolves around Comets (read more here: https://x.com/MeteoraAG/status/1998748611233067200)
(e) Control surface reliance
There is no anticipated change to the protocol’s governance/control model.
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.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
CG Corporate Services | Labs | Sole Director (nominee) | CG (Cayman) Corporate Services is a Cayman exempted company incorporated 10 November 2023, providing corporate administration services. |
Yong Zhen Hoe | Labs | Co-founder | Helped build Mercurial’s early product era and stepped in to become Meteora’s project co-lead after Ben Chow stepped down. |
Barbara Padega | Foundation | Director | Independent Director based in the Cayman Islands, Cayman Islands. Her career spans leadership roles at top-tier offshore firms, and is responsible for impartial, objective oversight to ensure ethical conduct and protect stakeholder interests. |
Intershore Consult (Cayman) Ltd. | Foundation | Company Secretary | Cayman Islands-based registered office provider offering trust administration, corporate services, and wealth management. |
CG (Cayman) Corporate Services | Foundation | Supervisor of the Foundation | Same corporate services entity described above under Solaris Labs. |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (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 onchain 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) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).
(d) Value accrual & holder rights
$MET token holders benefit from a straightforward value approach built on three pillars:
- Grow Revenue Focus on increasing the revenues generated across liquidity infrastructure. More volume, more integrations, more usage so as to drive sustainable protocol income.
- Manage Expenses Responsibly Run lean and allocate capital with discipline, ensuring that operating costs don't erode the value the protocol creates.
- Decrease Circulating Supply Conduct discretionary buybacks of MET tokens using protocol revenues for strategic purposes. The first priority is always re-allocating value back into Meteora. Buybacks are funded from revenues after committing what's needed to grow the protocol. The best thing that can be done for token holders long-term is building something undeniably valuable and rewarding users along the way.
Blockworks note: There is no DAO.
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are 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) and an explanation of any subsidiary entities.
- (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; "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
Meteora Foundation - Primary Foundation Exempted Limited Guarantee Foundation Company incorporated in the Cayman Islands.
(b) IP ownership & control
The Foundation holds a perpetual, royalty-free license from Solaris Labs Ltd to use, commercialize, sublicense, and generate revenue from the Meteora protocol and associated IP. Revenue generated accrues to a treasury owned by the Foundation.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
There is no DAO. Meteora Foundation has full control over the treasury, operating under 4-of-7 or 3-of-5 signer thresholds distributed across independent team members.
(d) Powers over DevCo
The Foundation's influence over Solaris Labs Ltd is governed by the Services Agreement dated 5 June 2025, under which the Foundation engages Solaris Labs as an independent contractor for protocol development and maintenance. The Foundation may direct and require services, revoke or alter instructions and terminate the agreement for cause.
(e) Contract/admin powers
The Foundation has full pause/upgrade authorities via a 4-of-7 or 3-of-5 multisig.
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are 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) and an explanation of any subsidiary entities.
- (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
Solaris Labs Ltd - Dev Co BVI Business Company, incorporated in the British Virgin Islands.
(b) IP ownership & control
Solaris Labs Ltd has rights to all intellectual property rights in the Meteora protocol software, including protocol codebases, on-chain programs, SDKs, technical documentation, and all derivative works. Solaris Labs does not control any subsidiaries that hold protocol IP. The IP is licensed to Meteora Foundation under a worldwide, non-exclusive, perpetual, irrevocable, transferable, royalty-free license.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
There is no DAO. Solaris Labs Ltd does not exert any form of direct or indirect influence over the Foundation's treasury.
(d) Powers over Foundation
Solaris Labs Ltd does not exert any form of direct or indirect influence over decision-making of the Foundation.
(e) Contract/admin powers
Solaris Labs Ltd has no pause/upgrade/governance-executor authorities.
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
- (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
- (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
- (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — The ticker/market symbol.
- (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
- (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
(a) Launch supply totals
i. Circulating $MET at TGE
480,000,000 (48% of total supply) ii. Non-circulating $MET at TGE: 520,000,000 (52% of total supply)
(b) Recipient categories & use of funds
i. Mercurial Stakeholders
15% of total supply Meteora is a rebranded project and team from Mercurial. We are the direct legacy of Mercurial, sharing key team members and core technology. Mercurial raised off a SAFT in 2021, and launched as a token on FTX. A snapshot was taken, forming the foundation for $MET today. 20% of MET goes towards Mercurial stakeholders since Meteora was built with the early financing support and users from Mercurial. Read more here: https://meteoraag.medium.com/unveiling-the-meteora-plan-8b4164d8a5a5 ii. Mercurial Reserve 5% of total supply This is a discretionary pool to support MER holders affected by FTX, pending verification and fair distribution. It remains part of circulating supply since it is intended for retail MER stakeholders, but it will not be immediately claimable until due process is completed. Read more here: https://medium.com/r?url=https%3A%2F%2Fmeteoraag.medium.com%2Ffrom-mercurial-to-meteora-my-story-caafd372a577 iii. LP Stimulus Plan 15% of total supply The focus here is to reward the most valuable users of Meteora — our early adopters, as well as our long-term liquidity providers. As such, the airdrop has been split into 3 key portions:
- 2% of total supply: fixed allocation for all users of Meteora before June 2025
- 8% of total supply: linear allocation for all users of Meteora before Jan 2025
- 5% of total supply: linear allocation for all users of Meteora from Jan 2025 to June 2025 Recipients of the airdrop can choose to receive their token allocations as 1) just tokens or as 2) an NFT representing a single-sided liquidity position in the MET/USDC DAMM V2 pool. Depending on how many recipients choose to receive their tokens as a NFT position, up to 7% of total supply (~46% of tokens in this bucket) will be distributed as an LP position to users. These LP positions then earn fees from trading volumes from the moment TGE goes live. This serves a key purpose of showcasing Meteora’s tech to new and existing users alike. The LP Range will be released closer to TGE. Holders can choose to leave their tokens in the LP, or claim and withdraw them to sell, hold or even deposit into a different LP Pool that they create or another holder creates. Read more here: https://proposals.meteora.ag/t/draft-amendments-to-lp-stimulus-plan/1330 iv. Launchpads 3% of total supply To foster a thriving ecosystem of Launchpads, tools and more, 3% of total supply will be allocated to current and future contributors to the Meteora Launchpad ecosystem through the following portions:
- 1.5% of total supply: linear allocations to all launchpad pool deployers and depositors
- 0.5% of total supply: tier-based airdrop to users of Meteora’s DBC
- 1% of total supply: used to form the Launchpad Ecosystem Reserve to bolster further innovation, bootstrap experimentation of cool launchpads, and promote the proliferation of new asset classes and new metas Read more here: https://proposals.meteora.ag/t/draft-amendments-to-lp-stimulus-plan/1330#p-2313-separate-allocation-of-3-for-launch-pools-and-launch-pads-4
v. Off-Chain Contributions
2% of total supply We initially allocated 2% of Supply towards DAO and Off-Chain Contributors who supported Meteora. We are distributing 1.2% of MET at TGE towards high quality leaders + anyone who supported Meteora via X posts, Discord discussions, feedback and more. The remaining 0.8% will be distributed across the first 1 year in compensation and incentives to external community contributors. Read more here: https://proposals.meteora.ag/t/2-dao-stimulus/201 vi. Jupiter Stakers 3% of total supply In our mission to grow the LP Army 10x, and to commemorate our long standing bond with the Jupiter ecosystem, $JUP Stakers will be included in the $MET TGE, receiving their airdrop as LP positions. Read more about the LP Distributor here. Read more here: https://proposals.meteora.ag/t/draft-proposal-distribute-3-out-of-the-tge-reserve-to-jupiter-stakers/2962 vii. M3M3 Plan 2% of total supply Recognizing that a majority of M3M3 tokenholders adopted and supported the $M3M3 token because of Meteora’s participation, 2% of our team’s 20% $MET allocation (not additional supply) will be distributed to the M3M3 stakeholders. Read more here: https://proposals.meteora.ag/t/draft-allocate-20-to-team-treasury-over-6-years/1331#p-2314-allocate-2-of-met-towards-m3m3-stakeholders-3 viii. TGE Reserve 3% of total supply To be used for Liquidity Provision, Market-Making, and other purposes during TGE. Any unused tokens will be returned to the Meteora Reserve. ix. Team 18% of total supply Vested linearly over 6 years to maintain the team’s alignment with Meteora’s long term growth plans.
x. Meteora Reserve
34% of total supply Vested over 6 years, tokens in this bucket are to be used as liquidity mining rewards after TGE, to be strategically leveraged by the Meteora Team to attract liquidity providers. Exact allocation plan TBA.
(c) Initial price per token (if applicable)
$0.50
(d) Ticker / market symbol
$MET
(e) Total supply & supply regime
1,000,000,000 - fixed supply.
(f) Initial vesting / release schedules
- Bucket: Mercurial Stakeholders
- % of Total Supply: 15%
- % of Total Supply Unlocked at TGE: 15%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: Mercurial Reserve
- % of Total Supply: 5%
- % of Total Supply Unlocked at TGE: 5%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: LP Stimulus Plan
- % of Total Supply: 15%
- % of Total Supply Unlocked at TGE: 15%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: Launchpads & Launchpool Ecosystem
- % of Total Supply: 3%
- % of Total Supply Unlocked at TGE: 3%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: Off-Chain Contributions
- % of Total Supply: 2%
- % of Total Supply Unlocked at TGE: 2%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: Jupiter Stakers
- % of Total Supply: 3%
- % of Total Supply Unlocked at TGE: 3%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: M3M3 Plan
- % of Total Supply: 2%
- % of Total Supply Unlocked at TGE: 2%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: TGE Reserve
- % of Total Supply: 3%
- % of Total Supply Unlocked at TGE: 3%
- Cliff(Months): 0
- Vest(Months): 0
- Bucket: Team
- % of Total Supply: 18%
- % of Total Supply Unlocked at TGE: 0%
- Cliff(Months): 1
- Vest(Months): 72
- Bucket: Meteora Reserve
- % of Total Supply: 34%
- % of Total Supply Unlocked at TGE: 0%
- Cliff(Months): 1
- Vest(Months): 72
- Bucket: Total
- % of Total Supply: 100%
- % of Total Supply Unlocked at TGE: 48%
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, 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. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
- Executed airdrop: Meteora has already completed its airdrop on 23 Oct 2025. Tokens could be claimed either as tokens or as an NFT that pointed to a single-sided LP position that was initialised before TGE. Up to 10% of the total supply elected to claim their tokens as an NFT position instead of just the tokens. CSV dump with token allocation by segments here: (very large file, please download to view)https://drive.google.com/file/d/14FjjROQ01MqeF6IHwDTCePtClxNpmZeB/view?usp=sharing
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; doing so earns full credit. 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) without describing trading strategy or expected outcomes.
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
- Market Maker Name: Tophash
- Token Allocation Committed: 0.6%
- Term Duration: 12 months
- Structure Name: Loan
- Market Maker Name: Selini
- Token Allocation Committed: 0.4%
- Term Duration: 12 months
- Structure Name: Loan
CEX / DEX 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: Binance
- Token Allocation Committed: 0.52%
- Term Duration: NA
- Native Token Listing Fees: 2,000,000 BNB security deposit
- Exchange Name: OKX
- Token Allocation Committed: 0.15%
- Term Duration: NA
- Native Token Listing Fees: NA
- Exchange Name: Bybit
- Token Allocation Committed: 0.106%
- Term Duration: NA
- Native Token Listing Fees: NA
- Exchange Name: Kraken
- Token Allocation Committed: 0.01145%
- Term Duration: NA
- Native Token Listing Fees: NA
- Exchange Name: Bithumb
- Token Allocation Committed: 0.01%
- Term Duration: NA
- Native Token Listing Fees: NA
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.").
Blockworks note: No prior raises conducted.
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 (optional) — References (optional): link(s) to post-mortem/advisory/PR.
(f) References (optional)
Blockworks note: No prior exploits as of 2026-02-03
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 TGE and Listings: The MET token was generated on 23 October 2025 via the Solana blockchain. As a decentralized protocol token, MET is not listed on centralized exchanges as a primary distribution channel — it was distributed via on-chain airdrops and LP positions. However, evolving or conflicting regulations across jurisdictions could impact the ability of secondary trading venues (DEXs and CEXs) to support MET trading pairs, restrict access for users in certain regions, or impose registration or licensing requirements on the token or its associated entities. Changes to securities classifications in key markets (e.g., the US, EU under MiCA, or Asia-Pacific jurisdictions) could affect the token's characterization and the legality of its distribution or trading. Entity-Level Regulatory Impact: Meteora's legal structure comprises foundations incorporated in the British Virgin Islands (BVI) and the Cayman Islands, overseen by reputable nominee directors acting as fiduciaries. The development team operates through a contracting entity (Solaris Labs), compensated by the foundation in USDC and tokens. Regulatory changes in the BVI, Cayman Islands, or jurisdictions where team members operate could impose new licensing requirements, enforce structural changes to the foundation or contracting arrangements, or trigger enforcement actions. Shifts in global AML/KYC requirements, sanctions regimes, or crypto-specific regulations could require restructuring of operations, entity dissolution, or relocation of the legal domicile. There are no external investors or venture stakeholders with claims on token supply post-TGE, which simplifies the entity structure but does not eliminate regulatory exposure. Jurisdictional & User Access Restrictions: Meteora's core protocol is permissionless and accessible to any user with a Solana wallet. However, certain front-end interfaces or partner platforms may implement geo-restrictions in compliance with applicable law, including restrictions for US persons and users in sanctioned countries (e.g., OFAC-designated jurisdictions such as North Korea, Iran, Cuba, Syria, and the Crimea region). Users who circumvent such restrictions do so at their own risk, and Meteora bears no liability for losses incurred in connection with restricted access or enforcement actions. These restrictions may limit the addressable user base and could evolve as regulatory landscapes change.
(b) Protocol, Technology & Security Risks
Bugs and Design Flaws: Meteora's core protocol comprises multiple on-chain programs deployed on Solana, including the DLMM Program, DAMM V2 Program, Dynamic Bonding Curve (DBC), Token Distributor Program, Liquidity Distributor Program, and the Jupiter Lock / Meteora Lock Program. As with any smart contract system, there is an inherent risk that bugs, design flaws, or implementation errors exist in these programs that could lead to loss of funds, incorrect fee calculations, improper token distributions, or disruption of liquidity pools. Meteora's programs interact with Solana's SPL Token Program and rely on the security of the underlying Solana runtime (BPF Upgradeable Loader). Vulnerabilities at the Solana network layer, in upstream dependencies (e.g., the SPL Token Program), or in Meteora's own programs could result in exploitation. Additionally, the merkle tree cryptography used in the Token and Liquidity Distributor programs, if improperly implemented, could lead to incorrect airdrop distributions or unauthorized claims. Security Measures & Their Limitations: All core Meteora programs have undergone independent security audits. Audit reports for DLMM, DAMM V2, Meteora Lock, and the distributor programs are publicly available via Meteora's documentation. The SPL Token Program used for MET itself has been audited by Anza (formerly Solana Labs). Critical protocol operations are governed by multi-signature wallets powered by Squads (v3 for cold wallets with 4/7 quorum, v4 for hot wallets with 3/5 quorum), reducing single-point-of-failure risk. The MET token's mint authority has been burned and freeze authority was never initialized, preventing unauthorized token minting or freezing. Despite these measures, audits are point-in-time assessments and may not detect all vulnerabilities, particularly those arising from novel attack vectors, economic exploits, or complex interactions between Meteora's programs and external protocols (e.g., Jupiter aggregator routing). Multi-sig wallets mitigate but do not eliminate key compromise risk. Program upgrade authority resides with the team multi-sig, meaning protocol upgrades are possible — which provides flexibility for bug fixes but also introduces a trust assumption. There is no formal on-chain governance mechanism or timelock currently governing contract upgrades.
(c) Token Economics, Unlocks & Incentive Risks
Critical Economic Assumptions: Meteora's protocol revenue — and by extension, the economic utility of MET — depends on sustained on-chain trading volume across DLMM, DAMM, and DBC pools. Key assumptions include: (1) continued demand for trading of memecoins, new token launches, and emerging asset classes on Solana, which collectively drive ~80% of Meteora's DEX volumes; (2) the continued competitiveness of Meteora's fee structures; (3) the sustained engagement and growth of the LP Army, whose liquidity provision is the foundation of fee generation; and (4) the continued vibrancy of the launchpad ecosystem and pipeline of new token launches using Meteora's DBC infrastructure. If Solana trading volumes decline materially, if competitors capture significant market share, if memecoin or ICM narratives fade, or if LP incentives prove insufficient to retain liquidity providers, protocol revenues could decline significantly. The Meteora Reserve (34% of supply, vesting over 6 years) is earmarked for future incentive programmes. If these incentives fail to attract or retain LPs, the protocol's competitive position and fee generation could deteriorate. Revenues are inherently cyclical and volatile, with high correlation to Solana ecosystem activity and crypto market sentiment. Governance Control over Monetary Policy & Rewards: MET has a fixed total supply of 1,000,000,000 tokens with mint authority permanently burned, meaning no additional tokens can ever be created. However, the Meteora team retains significant discretion over several economic parameters. The Meteora Reserve (34% of supply) is controlled by a team multi-sig (4/7 cold wallet) and may be deployed for future incentive programmes. The timing, magnitude, and allocation of these distributions are at the team's discretion and could materially affect token supply dynamics and market price. The team also controls protocol fee parameters (take rates on DLMM, DAMM, and DBC pools), which can be adjusted and could affect LP returns and trading competitiveness. Additionally, the team can direct treasury operations including token buybacks, strategic investments, and operational expenditures. There is currently no formal on-chain governance mechanism giving tokenholders voting power over these decisions.
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. Meteora is solely responsible for the content, accuracy, and legality of its disclosures.