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
Ordr is a fully on chain order book exchange on Solana that gives market makers their own private accounts, cheap repricing, and protection from toxic arbitrage. The result: tighter spreads and better prices for everyone
(b) Operational priorities
Months 1–2: Tightening existing code and engaging a security audit. Resolving audit findings and expanding private mainnet alpha.
Month 3: Public mainnet launch with first markets live, bootstrapped by in-house market making. Initiating aggregator integrations.
Month 4: Shipping the Maker SDK and documentation. Onboarding at least one aggregator to drive volume. Beginning institutional market maker outreach.
Month 5: Making the taker side composable for broader aggregator capture. Shipping a retail market making app.
Month 6: Onboarding first external market makers. Targeting 100M spot volume.
Ongoing operations are funded by a $150K ICO raise allocated as: 60% operating runway ($15K/month covering 4 engineers, market making ops, and infrastructure), 20% security audit, and 20% protocol-owned liquidity. Post-launch, the protocol generates revenue from taker fees from day one, creating a path to self-sustaining operations.
(c) High-level project overview
Ordr replaces closed, operator-controlled proprietary AMMs (propAMMs) with an open order book where any market maker can participate. The protocol combines three core components:
- Private order books per maker. Each market maker gets their own on-chain book account, eliminating shared-state write-lock contention that plagues legacy CLOBs on Solana. No contention means makers can quote tighter spreads across more markets.
- Near-free repricing. Hot paths are hand-optimized in sBPF assembly (28 CU per operation), making quote updates practically free with guaranteed transaction landing. Makers can reprice as often as their strategy demands.
- ACE (Application Controlled Execution). Built directly with the Jito engineering team using Jito's BAM (Block Auction Marketplace), ACE gives makers execution priority over arbitrageurs. Quote updates land top-of-block, protecting makers from toxic flow extraction that typically widens spreads.
(d) Primary token functions
$ORDR is the governance token of the Ordr protocol, used for decision-making through a Futarchy-based DAO powered by MetaDAO.
(e) Control surface reliance
The protocol's governance and control is fully managed through the MetaDAO futarchy framework. All protocol decisions, including parameter changes and treasury allocation, are determined by futarchy-based prediction markets where $ORDR holders participate. There are no plans to transition away from this 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.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Vinaya Prasad R | CEO & Co-Founder | 4+ years professional experience, 2 on Solana. Writes sBPF assembly for machine level optimization. Contributor to Blueshift and Agave. Arcium fellow, top of class in the Solana Foundation x Rektoff Rust Security program, top 0.5 percentile in India's JEE. |
Avhi Mazumder | CTO & Co-Founder | 2+ years on Solana. Contributor to Agave, Blueshift, Anchor, MagicBlock. Built a transaction scheduler, a C implementation of Turbine shredding, and kernel-level systems code. Won the global Solana Privacy Hack. Superteam member, multiple grant winner. |
Manoj Dasari | CIO & Co-Founder | Shipped a Solana client extension merged into Surfpool with mentions from the Solana Foundation and Turbin3. Won the Chainlink Block Magic and Push BRB hackathons. Top auditor from the Rektoff x Solana Foundation Rust Security program. |
Arjun Cheviri | COO & Co-Founder | 4 years in software, 2+ on Solana. Contributor to Agave, MagicBlock, Blueshift, TapeDrive. Built lotry.fun ($50K+ volume), won 11+ hackathons. Created Chio (60+ stars) and solana-program-list (90+ stars). Solana Summer Fellowship 2024, Arcium Fellowship 2025 (top 3, grant). Master's in CS with AI/ML. |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
None | None | None |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
MetaDAO futarchy protocol | None | None |
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
The project's intellectual property, including codebases/repos and any associated trademarks/brands, is held by a Cayman Islands SPC (Segregated Portfolio Company) formed via MetaLeX. The SPC is governed by the DAO.
(b) Contract/admin powers
Governance is fully onchain and permissionless via the MetaDAO futarchy protocol on Solana. Token holders make decisions by trading conditional outcome tokens on proposal markets. Proposals pass or fail based on market-determined price impact on the project's token.
Program is not deployed yet.
(c) Locked-token rights (conditional)
The price-based performance premine tokens are locked with a minimum 18-month cliff and unlock based on sustained price performance milestones. Locked token holders do not have additional governance or decision-making rights beyond what unlocked token holders have. Locked tokens cannot vote or participate in governance until unlocked.
(d) Current tokenholder governance rights and economic arrangements
Token holders govern the DAO treasury through futarchy-governed proposals. The DAO treasury funds development directly there is no separate development company. Revenue distribution and treasury allocation decisions are made via onchain governance proposals.
(e) Control surface reliance
The protocol's governance and control is fully managed through the MetaDAO futarchy framework. All protocol decisions, including parameter changes and treasury allocation, are determined by futarchy-based prediction markets where $ORDR holders participate. There are no plans to transition away from this model.
(f) Dissolution authority
Dissolution of the DAO would require an onchain futarchy governance proposal passed by the market. The Cayman SPC legal wrapper can be wound up per its constitutional documents as directed by DAO governance.
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
Each project launched through MetaDAO Accelerated has a Cayman Islands SPC (Segregated Portfolio Company) entity formed via MetaLeX. The entity holds the project's intellectual property and is governed by the DAO. There is no separate development company the DAO treasury funds development directly through futarchy-governed proposals.
(b) IP ownership & control
The project's intellectual property, including codebases/repos and any associated trademarks/brands, is held by a Cayman Islands SPC (Segregated Portfolio Company) formed via MetaLeX. The SPC is governed by the DAO.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No foundation entity exists. All powers over DAO governance, treasury actions, protocol-controlled resources, token administration, and reward parameters are governed by the MetaDAO futarchy framework. Decisions are determined by futarchy-based prediction markets where $ORDR holders participate. There is no centralized entity with unilateral authority over any of these functions.
During the initial launch phase, the founding team holds program upgrade authority for security purposes. This authority will be transferred to the DAO as the protocol matures.
No program deploy yet
(d) Powers over DevCo
No foundation entity exists. There is no separate DevCo entity. The protocol is built and maintained by a four-person founding team. Development priorities are subject to governance through the MetaDAO futarchy framework. No foundation or external entity exerts direct or indirect influence over development decision-making.
(e) Contract/admin powers
No foundation entity exists. During the initial launch phase, the founding team retains program upgrade authority over the deployed Solana programs for security and operational purposes. There are no pause authorities. No governance-executor, veto, or super-majority mechanisms exist outside of the MetaDAO futarchy framework. Program upgrade authority will be transferred to the DAO as the protocol mature
(f) Current economic arrangements and distribution policies
No foundation entity exists. No governance-approved, contractual, or programmatic mechanisms currently direct protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions to any foundation entity, its equityholders, contributors, or other participants. Taker fees flow to the protocol treasury and are governed by the MetaDAO futarchy framework. The founding team's only token allocation is the Performance Package (12.9M tokens, 50% of supply), which is subject to an 18-month cliff and price-based vesting milestones.
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
No separate DevCo entity exists. The protocol is developed by a four-person founding team operating independently without a formal corporate entity.
(b) IP ownership & control
No separate DevCo entity exists. The project's intellectual property, including codebases/repos and any associated trademarks/brands, is held by a Cayman Islands SPC (Segregated Portfolio Company) formed via MetaLeX. The SPC is governed by the DAO.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DevCo entity exists. The founding team holds program upgrade authority during the initial launch phase for security purposes. All other powers over governance, treasury, and protocol-controlled resources are governed by the MetaDAO futarchy framework. Program upgrade authority will be transferred to the DAO as the protocol matures.
(d) Powers over Foundation
No DevCo entity exists. No foundation entity exists. There is no relationship to describe.
(e) Contract/admin powers
No DevCo entity exists. The founding team retains program upgrade authority over deployed Solana programs during the initial launch phase. There are no pause authorities. No governance-executor, veto, or super-majority mechanisms exist outside of the MetaDAO futarchy framework. Program upgrade authority will be transferred to the DAO as the protocol matures.
(f) Current economic arrangements and distribution policies
No DevCo entity exists. No governance-approved, contractual, or programmatic mechanisms currently direct protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions to any DevCo entity. The founding team's only economic interest is the Performance Package (12.9M tokens, 50% of supply), subject to an 18-month cliff and price-based vesting at 2x, 4x, 8x, 16x, and 32x ICO price milestones measured via 3-month TWAP.
Token Supply & Allocations
Initial Allocation
Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.
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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ORDR | 2026-07-31 | Initial Float (ICO Participants) | Public / Sale | 38.8 | 10000000 | 1 | 10000000 | 0 | 0 | 0 | 0 | No | Distributed pro-rata to all ICO participants based on contribution; fully unlocked and freely transferable at TGE. ICO priced at $0.015/token, $150,000 raised = 10,000,000 tokens. SOURCE PENDING: terms supplied by issuer, primary source URL not yet provided. | |
ORDR | 2026-07-31 | Futarchy AMM (Protocol-Owned Liquidity) | Liquidity | 7.8 | 2000000 | 1 | 2000000 | 0 | 0 | 0 | 0 | Conditional | 2,000,000 tokens paired with 20% of ICO proceeds ($30,000 of the $150,000 raise) in a Futarchy AMM pool; protocol-owned liquidity, implied pairing price $0.015/token. Circulating Treatment = Conditional because the tokens sit in a protocol-controlled pool and require market purchase, not merely unlock, to reach public hands. SOURCE PENDING: terms supplied by issuer, primary source URL not yet provided. | |
ORDR | 2026-07-31 | Meteora LP (Protocol-Owned Liquidity) | Liquidity | 3.5 | 900000 | 1 | 900000 | 0 | 0 | 0 | 0 | Conditional | 900,000 tokens deployed as single-sided liquidity on Meteora at $0.015/token ($13,500 notional); protocol-owned. Circulating Treatment = Conditional for the same reason as the Futarchy AMM row: entry into circulating supply depends on market purchase from the pool rather than on unlock alone. SOURCE PENDING: terms supplied by issuer, primary source URL not yet provided. | |
ORDR | 2026-07-31 | Performance Package (Team) | Insiders | 50 | 12900000 | 0 | 0 | 18 | 0 | 0 | 0 | Conditional | Team performance premine. 18-month cliff from TGE (cliff date 2028-01-31), then 5 tranches of 20% (2,580,000 tokens each) unlocking on PRICE milestones of 2x/4x/8x/16x/32x the $0.015 ICO price ($0.030, $0.060, $0.120, $0.240, $0.480), each confirmed over a 3-month TWAP evaluation period. PRICE-CONTINGENT, NOT TIME-BASED: this template models time-based unlocks only, so no unlock schedule can be expressed for this row (Linear Vesting Months = 0); the monthly projection grid never releases these tokens, while the row-level check credits the full 12,900,000 at the cliff. Actual unlock timing is indeterminate and depends on market price. Circulating Treatment = Conditional because elapsed time alone never releases these tokens. Cadence Months entered as 1 rather than 0 only because a 0 cadence triggers a divide-by-zero in the validation engine; it has no effect where there is no linear vest. SOURCE PENDING: terms supplied by issuer, primary source URL not yet provided. | |
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 | |||||||||||||
ORDR | 2026-07-31 |
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.
There are no airdrops as part of the MetaDAO Accelerated ICO process. All token distribution occurs through the permissionless ICO mechanism. Any future token distributions would need to be passed via DAO governance proposal following the ICO and are not part of this launch.
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 |
|---|---|---|---|
There are no market maker agreements. Liquidity is provided through the Accelerated launch mechanism's built-in liquidity pool, which receives 20% of funds raised. There are no token loans, OTC deals, or designated market maker arrangements. | 0 | 0 | 0 |
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 |
|---|---|---|---|
There are no CEX listing agreements. The token trades onchain on Solana DEXs from the moment of launch. No listing fees have been paid, and no exchange has been granted tokens or preferential access. | 0 | 0 | 0 |
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 |
|---|---|---|---|---|
MetaDAO Presale | N/A (Initial Public ICO) | 27-July-2026 | 10,000,000 | 18 Months |
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
Not applicable. No exploits or incidents have occurred as of 2026-07-28. The token has not yet been issued.
(b) Exploit vector summary
Not applicable. No exploits or incidents have occurred as of 2026-07-28.. The token has not yet been issued.
(c) Quantified impact
Not applicable. No exploits or incidents have occurred as of 2026-07-28. The token has not yet been issued.
(d) Remediation/response taken
Not applicable. No exploits or incidents have occurred as of 2026-07-28. The token has not yet been issued.
(e) Current status
Not applicable. No exploits or incidents have occurred as of 2026-07-28. The token has not yet been issued.
(f) References
Not applicable. No exploits or incidents have occurred as of 2026-07-28. The token has not yet been issued.
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
Token classification. The governance token may be classified differently across jurisdictions. If any regulator determines it constitutes a security rather than a governance or utility token, the project and token holders could face registration requirements, trading restrictions, or enforcement actions. The U.S. SEC’s evolving position on governance tokens, and parallel developments in the EU (MiCA), Singapore (MAS), and other jurisdictions, create ongoing uncertainty that the project cannot resolve unilaterally.
Entity-level regulatory risk. The project operates under a Marshall Islands DAO LLC structure. While the Marshall Islands has adopted favorable digital asset legislation, this jurisdiction may face diplomatic, banking, or regulatory pressure that creates operational friction. Regulatory changes in any jurisdiction where the development team operates, token holders reside, or users access the protocol could impose licensing requirements, restrict operations, or compel structural changes to the DAO LLC or its governing arrangements.
MetaDAO protocol dependency. The project’s governance infrastructure is provided by MetaDAO, which is currently in beta. MetaDAO’s documentation discloses that the MetaDAO team currently retains the ability to override decision markets in extreme scenarios. Changes to MetaDAO’s protocol, terms, or operational status could affect the project’s ability to conduct governance or complete token-related actions.
Tokenholder tax treatment. The tax treatment of ownership tokens is uncertain and varies significantly across jurisdictions. Depending on jurisdiction, taxable events may include receipt of tokens at TGE, trading or transferring tokens, participating in governance markets, or receiving any future distributions authorized by governance. Token holders are solely responsible for determining and complying with their own tax obligations. The project does not provide tax advice and makes no representations regarding tax treatment.
Jurisdictional access. Token holders and users are responsible for ensuring their participation complies with applicable laws in their own jurisdiction. The project makes no representation that holding or trading the token is lawful in any particular jurisdiction.
(b) Protocol, Technology & Security Risks
Smart contract vulnerabilities. Logic errors or implementation flaws in the project’s on-chain programs could result in loss of funds or unintended behavior. No audit process eliminates all risk; vulnerabilities may exist that audits, internal review, or community testing fail to detect, including novel attack vectors that emerge after deployment.
Solana runtime dependency. The project’s contracts execute on Solana. Changes to Solana’s compute limits, runtime behavior, validator set, or network stability could disrupt contract execution or proof verification. A Solana network outage or consensus failure would render on-chain governance and treasury operations temporarily inaccessible.
MetaDAO decision market dependency. Governance, including all treasury actions and token issuance, is routed through MetaDAO’s decision market infrastructure. A bug, exploit, or operational failure in MetaDAO’s contracts could prevent proposals from being created, resolved, or executed, effectively freezing governance until the issue is resolved.
Decision market liquidity and manipulation risk. Proposal markets rely on sufficient trading participation to produce accurate price signals. Thin liquidity in PASS or FAIL markets, particularly for smaller or less actively traded projects, could allow a single large participant to influence a TWAP outcome. MetaDAO’s lagging TWAP mechanism mitigates but does not eliminate this risk.
AMM liquidity pool risk. A portion of ICO proceeds and tokens are deployed to an AMM liquidity pool at launch. Impermanent loss, pool imbalances, or low liquidity depth could affect the tradability of the token and the value of treasury-held liquidity positions.
(c) Token Economics, Unlocks & Incentive Risks
Performance tranche unlock pressure. Team tokens, where applicable, unlock in tranches tied to price milestones (2x, 4x, 8x, 16x, and 32x of ICO valuation). Each milestone, if reached, creates a discrete unlock event that may result in selling pressure as recipients become able to claim and liquidate tranches.
Governance can authorize new token issuance. Mint authority over the token sits with the DAO treasury, governed by MetaDAO’s decision market mechanism. A governance proposal that passes could authorize the issuance of additional tokens, which would dilute existing holders. Token holders cannot assume the current supply is a permanent ceiling.
Governance participation risk. Decision markets require active, capitalized participation to function as intended. If governance markets are thinly traded, due to low token holder engagement, small float, or poor market depth, proposal outcomes may reflect the preferences of a small number of participants rather than the broader holder base. Apathetic or concentrated governance could lead to outcomes that are adverse to the majority of token holders.
Treasury concentration risk. All ICO proceeds flow into a single on-chain treasury governed by decision markets. A successful malicious proposal, a smart contract exploit targeting the treasury, or a sustained period of governance dysfunction could result in partial or total loss of treasury assets with limited recourse.
Protocol revenue assumptions. Value accrual to the token depends on the protocol generating meaningful usage and, over time, revenue that governance allocates toward token holders. If the protocol fails to attract sustained usage, the treasury will not grow beyond ICO proceeds, and there is no mechanism guaranteeing any return to token holders other than a governance-authorized liquidation proposal
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. ordr.trade is solely responsible for the content, accuracy, and legality of its disclosures.