# For Entrepreneurs
Source: https://docs.metadao.fi/benefits/founders
Why should you launch your project on MetaDAO? A note from the founders
## Introduction
One way to frame MetaDAO is “a place for crypto-native enterprises to raise money that doesn’t suck.”
That is, if you need capital to build or grow your business, you have a few options available to you today:
1. Follow the standard path, selling token warrants to VCs and launching a token in 2-3 years
2. Raise venture capital and never launch a token
3. Collect creator fees from Pump / Believe / Heaven or a similar platform
4. ICO on Metaplex or a similar platform
5. Launch on MetaDAO
Of these five options, only the fifth is purpose-built for building a long-term crypto-native business.
### The standard path is bricked and will continue to get worse
The standard way of launching tokens (hyped TGE, paid CEX listings, 10% airdrop, Labs / Foundation / DAO, linear vesting, etc.) is not optimized for building a long-term business - it’s a playbook for extracting money from retail investors while evading securities laws.
If you try to use it to build a long-term business, you're going to have a bad time:
Some may believe that doing a venture round doesn’t lock you into this path. But we find
that once teams raise money, they feel pretty locked into it.
### Never launching a token is reasonable, even if it’s not maximally crypto-native
Some teams don’t plan to do tokens, instead accruing value to their equity as a normal start-up would.
We think this approach is reasonable. If you can raise money from investors who don’t expect a token, you should seriously consider it.
### Launching on a bonding curve is terrible
Recently, a few projects have launched on or considered launching on a platform like Pump, Believe, or Heaven. The main problems with these are as follows:
* You don’t raise much money - the median token only makes \$10k - \$100k in creator fees.
* These tokens don’t have any intrinsic value, and the market will recognize them as such. You may have lots of traders, but you will have few long-term holders
* Snipers will scoop up large percentage of your supply and sell onto your believers.
* “Hey, would you like to come work for our start-up for a below-market salary and 1% of the supply? Yes, someone was able to purchase 1% of the supply for \$150, but what does that matter?”
### Normal ICOs can work if you have enough trust, do the legal work, and avoid the pitfalls of the standard path
Another option is to launch at a place like Metaplex. Essentially, a 2018-style ICO where you’re given discretion over the money.
The problem you’ll encounter is that historically many, if not most, of these ICOs rugged. This has led to wariness among serious investors. So you may be able to get short-term token flippers, but it’ll be harder for you to attract long-term holders.
But if you have sufficient trust, and are willing to put in the legal work to align the token and the business and also to avoid following the “low float / high FDV” playbook, then this can be reasonable.
### MetaDAO is *the* place if you want to align a community the right way
But if you want to align a community by launching a token and you don’t want to do a bunch of legal, smart contract, and marketing work, MetaDAO is today the place to go.
On MetaDAO you get:
* A valuable token, which leads to longer-term and higher-quality holders
* Provable transparency - noone will wonder whether you've "OTCed"
* To enter the arena early
* A mintable token - you won't need to worry about running out of supply
* A potential community of early believers
It's not a free launch - there are plenty of trade-offs, including the psychological effects of having a liquid token that can go down.
But if we were launching a new crypto project today, MetaDAO is the place we’d want to be.
-Proph3t and Kollan House
# For Investors
Source: https://docs.metadao.fi/benefits/investors
For token investors, the pitch is simple - reduce the risk that you get rugged
## Overview
MetaDAO helps token investors in two ways:
* Mechanistic protection against treasury rugs
* Legal protection against revenue rugs
## Mechanistic protection against treasury rugs
On Solana in 2021 there were four big ICOs:
* **Parrot:** raised \$85M, [the team walked away with \$72M of it](https://www.coindesk.com/markets/2023/07/21/defi-project-parrot-puts-fate-of-over-70m-treasury-prt-token-to-vote)
* **UXD:** raised \$57M, [insiders walked away with \$46M of it](https://docs.google.com/spreadsheets/d/1VYv7qHD9kpfFeY_nBjT6jkqbA0HHf4w5gBVFRuN5OPU/edit?gid=1572994615#gid=1572994615)
* **Mango:** raised \$70M, [the founders are suing each other for stealing from the project](https://x.com/dj_d_sol/status/1843666330429600216)
* **Aurory:** raised \$108M, [the token is down 99.5% and it's unclear where the money has gone](https://coinmarketcap.com/currencies/aurory/)
On MetaDAO, all of the funds go to a market-governed treasury.
If someone tries to rug, anyone can raise a proposal
to return capital to tokenholders.
## Legal protection against revenue rugs
Famously, the [\$30m](https://dune.com/Marcov/uniswap-revenue) Uniswap has made from its frontend is retained solely by Uniswap Labs and will likely never end up in the hands of tokenholders.
Less famously, the Unibot team built Trojan, which made [\$206M in fees](https://defillama.com/protocol/fees/trojan), and decided to keep the revenue for themselves rather than integrating the \$UNIBOT token.
Because of the legal entity created at launch, tokenholders could sue teams that misappropriate the project’s revenues or compel service providers (domain name registrars, social media companies, etc.) to transfer control of IP to a new team.
# Ownership Coins
Source: https://docs.metadao.fi/benefits/ownership-coins
### **Overview**
Most tokens don't give you real ownership. The team controls the treasury, the IP, and a huge chunk of the supply. Token holders have no power. Founders can do whatever they want, including shutting it down and walking away with the money.
Ownership coins work differently. The valuable parts of the organization—intellectual property, treasury, mint authority—are controlled by decision markets.\[1] Legal documents and smart contracts enforce that this is the case. Teams must work to create tokenholder value or risk getting ousted by the markets.
There's no legal document saying that tokenholders own anything. But decision markets protect you from poor or biased decisions that would tank your tokens. What's good for the token is good for the token holder.
## **What makes a token an Ownership Coin?**
Two things:
* **Treasury governed by decision markets**: money sits in a treasury with market oversight so that the team can’t easily rug it.
* **Key IP governed by decision markets:** the key IP, which includes social media accounts, domain names, created software, and the like is assigned to an entity with decision market oversight. The team can’t build a product with tokenholder money and then rug them once the product is successful.
## **How "ownership" works under decision markets**
| Normal ownership | Decision markets |
| ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| Shareholders have a say and can vote | Market price *is* the decision |
| Shareholders have a contractual claim on residual equity value in the event of a liquidation or sale | Market price *is* the decision |
| Operators have a fiduciary duty to shareholders (or lienholders, in the case of insolvency) and can be sued for breach of that duty | Market price *is* the decision |
Even if teams maintain day-to-day control of decisions, they are ultimately responsible to a market that has a good deal of control over the organization. Funds can be withdrawn, operators can be replaced, key assets can be divested all by the market and without the approval of an executive team or board of directors.
\[1]: MetaDAO is currently in beta and the MetaDAO team currently has the ability to override decision markets in extreme scenarios, similar to Polymarket’s backdoor into the oracle. We have yet to use this power and expect it to disappear as the system matures.
# Trading Proposals
Source: https://docs.metadao.fi/governance/markets
How conditional markets work and how you can trade them
## Overview
Once a proposal has accumulated enough stake, the project takes half of its liquidity from the spot (e.g. META/USDC)
market and moves it into a proposal's conditional markets.
Traders can then make *conditional trades* over 3 days. **Conditional trades are like normal trades, except they
revert if the condition isn't met.**
## Example: Participating in the ORE Market
If you thought that ORE would have been worth more than \$19 if they reduced their emissions by
40%, you could have participated in [this market](https://v1.metadao.fi/ore/trade-v4/3PCPkFQQo7sU2DxpqnQNEttiyx1t5kByY2WPjCo1qLEZ):
![]()
If you believed that ORE would go to \$30 if they adopted this change, you could have bought ORE in the pass market.
For example, you could have placed a trade of \$1000 for 50 ORE (\$20 per ORE).
Then, if the proposal passes, you would have bought ORE at \$20. But if it fails, you wouldn't have bought any ORE.
## How you can preserve & grow your portfolio by trading decision markets
### Case #1 - Bad Proposal
Suppose there's a project, EXMPL, that has \$1M in its treasury and a \$1.2M
market cap. You own \$10,000 worth of the token.
The founder just raised a proposal to send all of the project's money to himself
so that he can go on a nice vacation.
The market immediately reacts to this information and the token shoots down to a
\$900k market cap. But so far, no one has traded the decision markets, so it's trading
\$900k in both the pass and fail markets - what should you do?
One reasonable course of action would be to sell pass and buy fail. Pass is
overvalued at \$900k if you think the token will go to 0 if the founder walks
away with all of the money. And fail is undervalued at \$900k if you think that
the immediate next proposal will be to liquidate, netting you a nice 11% profit.
You're prepared for either scenario.
### Case #2 - Good Proposal
Now suppose there's another project called XYZ with \$10M in revenues and a \$100M market
cap. So it's trading at a price-to-sales multiple of 10.
The founder just created a proposal to add a new business line.
You think that this business line will add \$5M of revenue to the project, translating to
\$50M in market cap.
Here, your course of action should totally depend on the prices of the decision markets.
If the pass market is already pricing the token at \$150M, you shouldn't take any trades.
But if it's trading at \$110M in the pass market, you probably want to buy. If it's trading
at \$200M, you probably want to sell.
And if you think that \$100M is the fair value for the project if the proposal fails, you
would probably want to buy the fail market at below \$100M and sell it above \$100M.
# Introduction to Decision Markets
Source: https://docs.metadao.fi/governance/overview
So, what is "market-driven governance"?
## First, some background
MetaDAO originally started as a governance project - since November 2023 we've run 96 proposals
for 14 organizations.
Decisions made on MetaDAO include:
* [Jito's fee switch decision](https://v1.metadao.fi/jito-dao/trade/CJW4iZPT14sVNzoc4Yibx1LbnY12sA75gZCP9HZk11UA)
* [Flash's decision to start passing revenue back to stakers](https://v1.metadao.fi/flash-trade/trade-v4/3kfEHobCtMn4rDCXmo2H735xX6oEacVN1DBuL41wj7az)
* [All of Sanctum's governance decisions](https://v1.metadao.fi/sanctum)
The difference between governance on MetaDAO and elsewhere is that there isn't any voting, only trading.
This system of governance is called decision markets.
## How does it work?
TL;DR:
* People trade in markets that correspond to "what would be the value of this token if this proposal passed?" and
"what would be the value of this token if this proposal failed?"
* Organizations accept a proposal when traders think it will make the token's value increase and reject them
when traders think it will make the token's value decrease
Here's its inventor Robin Hanson to explain the concept:
## Why is it better?
Markets have a long track record of predicting the future better than alternatives. For example:
* [Prediction markets have historically beaten pollsters at predicting election results.](https://www.biz.uiowa.edu/faculty/trietz/papers/long%20run%20accuracy.pdf)
* [Orange juice futures markets have historically predicted the weather better than
government forecasts.](https://www.asecib.ase.ro/mps/TheWisdomOfCrowds-JamesSurowiecki.pdf)
* [In 1986 when the Challenger Space Shuttle exploded over Cape Canaveral, it took the government
4 months to identify Morton-Thiakol's O-Rings as the root cause. The market had figured it out
within 16 minutes.](https://maloney.people.clemson.edu/challenger.pdf)
![]()
## Why does it matter?
We don't know if decision markets are quite at that level of intelligence yet, but they appear
to already be better than token-voting at preventing capture.
Concretely, this means it is harder to rug ICOs when the funds are stored in a treasury with decision market oversight.
Or, in the words of [Kevin Heavey](https://www.umbraresearch.xyz/writings/futarchy),
> Decision markets are such a radical improvement over majoritarian DAOs that even in its infancy it should already be ordained as the default governance mechanism, perhaps with training wheels like a security council to veto exploits.
> All DAOs that persist with token voting over decision markets should begin to feel increasingly uncomfortable, because in time it will be assumed that any DAO still carrying on this way is malicious or incompetent... If you want people to share ownership of your business, you either become a normal company with no governance token, or you bind your fate to decision markets and let the market decide.
> *Futarchy as Trustless Joint Ownership*, Umbra Research
# Creating Proposals
Source: https://docs.metadao.fi/governance/proposals
What proposals can do and how they go live
Anyone can create a proposal to a project. Proposals can:
* Spend USDC from the treasury
* Issue new tokens
* Update token metadata
* Increase or decrease the liquidity provided by the project's treasury
Once a proposal is created, holders must stake tokens on it for it to
go live. By default, a proposal requires between 200,000 to 1,500,000 tokens (1-15% of the ICOs 10M tokens)
staked on it for it to go live. This depends on the version of the DAO and the DAO parameters which can be updated from time to time.
Staking is purely to prevent spam and doesn't have lockups or risk of slashing.
There can only be one proposal live at once.
# Finalizing Proposals
Source: https://docs.metadao.fi/governance/twaps
How projects decide whether a proposal passes or fails
## TWAPs decide whether proposals pass or fail
The goal of futarchy is to accept proposals that increase the value of the project.
Unfortunately, you can't just take prices at the end of the proposal because
those could be easily manipulated.
So instead, we use time-weighted average prices (TWAPs).
## TWAPs are lagged to mitigate the effects of manipulation
Normal TWAPs also have their flaws. For example, a Solana validator could
manipulate a TWAP by setting the price extremely high for a few slots.
If said validator controlled 1% of slots, they could force a proposal
through by 100xing the pass price during their slots.
We deal with this by using a special form of TWAP we call a lagging price TWAP.
In a lagging price TWAP, the number that gets fed into the TWAP isn't the raw price - it's a number that tries to approximate the price but which can only move a certain amount per update.
We call the number that gets fed into the TWAP an *observation*.
![]()
To take an example, imagine that a market's initial observation is \$500
and it can change at most \$5 per minute. If market is currently trading
at \$550, it will take 10 minutes before the last observation reflects
the price.
## 24-Hour Delay Before TWAP Recording
Before TWAP recording begins, there is a **24-hour delay period**. This gives traders
time to properly price the market and evaluate the proposal before recordings start.
This delay is important in a permissionless system—it ensures that participants have
adequate time to analyze and react to new proposals rather than being caught off-guard
by immediate TWAP calculations.
## Pass Thresholds
MetaDAO uses different pass thresholds depending on the proposal type:
| Proposal Type | Pass Threshold |
| ------------------ | -------------- |
| Team Sponsored | -3% |
| Non-Team Sponsored | 3% |
**Team sponsored proposals** have a negative threshold (-3%), meaning they require
slightly less market confidence to pass. The rationale is that teams generally have
better context on what's good for their project.
**Non-team sponsored proposals** have a positive threshold (3%), making it slightly
harder for external proposals to pass than to fail. This provides a conservative
default for permissionless governance.
We're actively tuning these parameters. Check the DAO structure onchain to understand
exactly what thresholds have been configured for any specific organization.
For more context on the reasoning behind these threshold choices, see
[this discussion](https://x.com/metaproph3t/status/1979243370452258837).
# Are You Ready?
Source: https://docs.metadao.fi/how-launches-work/are-you-ready
Determining whether you're prepared and/or a fit for MetaDAO
## MetaDAO is built for early-stage, crypto projects
Eventually we'd like to support all kinds of businesses. But today we focus on crypto-native ones because they are most likely to benefit from [community ownership effects](https://docs.metadao.fi).
The ideal stage is when you have a working product / users but haven't raised significant capital yet.
![]()
It doesn't need to be pretty - this was an early version of MetaDAO!
## You need to be prepared to build in public and sell your vision
If you don't have a large community yet, that's okay! Tokens are one of the most effective community bootstrapping tools.
But you do need to be able to **effectively communicate what you're doing and why people should be bullish on you**. Your tokenholders will be globally distributed, which makes online communication - such as X articles and videos - key.
We recommend the following:
* At least 1 week of public lead up heading into the launch, with well-written articles and graphic tweets explaining what you're doing and why people should be bullish on you.
* Monthly updates that cover the state of the business (including your KPIs) and what you're focus will be.
* A Telegram group where you're responsive to people that have questions for you.
Because your treasury will have market oversight, this communication is not a nice-to-have, it is 100% critical. **Failure to communicate your vision effectively may lead to capital being returned to tokenholders from your treasury.**
# Bid Wall
Source: https://docs.metadao.fi/how-launches-work/bid-wall
How the bid wall supports token price and reduces supply
## Overview
**NOTE: The Bid Wall is deprecated.** It was used in one raise and has not been used since. Unless a launch specifically mentions the Bid Wall, assume it will not be used.
The **Bid Wall** lets token holders sell tokens back at the project's Net Asset Value (NAV) per token. Tokens sold into it are permanently burned, reducing supply.
Fully onchain Solana program — all operations transparent and verifiable.
## How It's Funded
The bid wall is funded from the ICO raise:
```
Bid Wall = Total Raised - (20% × Total Raised + Min Goal)
```
Or: `Bid Wall = 80% × Total Raised - Min Goal`
* **20% of total raised** → Liquidity pools (with 2.9M tokens)
* **Min goal** → Project treasury
* **Remainder** → Bid wall
## Example: $6M Minimum, $8M Raised
| Allocation | Calculation | Amount |
| ---------------- | ------------------ | ------------- |
| Liquidity Pools | 20% × \$8M | \$1,600,000 |
| Project Treasury | Min goal | \$6,000,000 |
| **Bid Wall** | $8M - $1.6M - \$6M | **\$400,000** |
If a project raises exactly its minimum, the bid wall gets nothing. If it raises less than 125% of minimum, the bid wall will be small or zero.
## What Price Does the Bid Wall Buy At?
The bid wall buys at **NAV per token**, which adjusts with treasury balance:
```
treasury_balance + lp_quote + bid_wall_quote
NAV per token = ------------------------------------------------
tokens_at_launch - tokens_bought_by_bid_wall
```
As the treasury spends USDC, NAV decreases. Dynamics:
* **At launch:** Bid wall price ≈ ICO price
* **After treasury spends:** Price decreases proportionally
* **Burns elsewhere:** NAV rises — selling into the bid wall becomes less attractive
## Example: Bid Wall Buying Power
$6M min / $8M raised, \$400K in bid wall:
| Scenario | Treasury Balance | Approx. NAV/Token | Tokens Buyable |
| ---------------- | ---------------- | ----------------- | -------------- |
| At launch | \$6M | \~\$0.60 | \~666,666 |
| After \$1M spent | \$5M | \~\$0.50 | \~800,000 |
| After \$3M spent | \$3M | \~\$0.30 | \~1,333,333 |
*Actual NAV includes LP balances and tokens already bought by the bid wall.*
## Why This Design?
**Self-adjusting floor.** The bid wall creates a price floor tied to actual treasury value. If the project spends, the floor reflects that.
**1% fee to MetaDAO.** When you sell: you get USDC at NAV minus 1%, tokens are burned, fee goes to protocol revenue. Fair exit, not profit mechanism. Fee may be adjusted.
**Anti-gaming.** Burning tokens outside the bid wall *increases* NAV (tokens removed, USDC stays). Selling into the bid wall becomes less profitable. You can't game it by reducing supply first.
## Verification
| What | How |
| --------------------- | ------------------------------------- |
| Bid wall USDC balance | Bid wall account on Solana Explorer |
| Tokens burned | Burn transactions in bid wall history |
| Current NAV | Formula above with onchain data |
## FAQ
20% goes to liquidity pools for trading. The bid wall gets what remains after liquidity and the minimum goal.
No. Onchain program restricts it to buy-and-burn only.
No more sales. After 90 days, remaining USDC can be returned to treasury. Tokens purchased are permanently burned.
Yes. 90-day expiry. After that, team can recall remaining USDC to treasury.
## Summary
| Aspect | Description |
| ------------- | --------------------------------------------------- |
| **Funding** | Total Raised - (20% × Total + Min Goal) |
| **Buy Price** | NAV per token (adjusts with treasury balance) |
| **Fee** | 1% to MetaDAO (may be adjusted) |
| **Duration** | 90 days, then remaining USDC can return to treasury |
| **Action** | Buys tokens from sellers, burns them |
# Getting Listed
Source: https://docs.metadao.fi/how-launches-work/create
What founders need to do to raise on MetaDAO
## What we need
To get listed, founders need to provide us with the following:
* **Project name and description:** what the project is called and why someone should want to participate in its upside, both a 1-2 sentence version and a longer version - [here's an example of the longer version](https://www.metadao.fi/projects/solomon/fundraise).
* **Token name and ticker:** for example, “Omnipair” and “OMFG.” We recommend using memorable and unique tickers.
* **Project image and (if different) token image:** what people will see on the MetaDAO site and on trading venues like Jupiter.
* **Minimum raise amount:** how much your project needs for you to go this path. If the project raises less than this amount the sale will be refunded. We recommend adding buffer for unexpected expenses and the 20% liquidity provision.
* **Monthly team budget:** how much the team needs every month from the treasury to operate normally. Spends that are larger than this need to be approved by governance. You can also configure this number later with governance. It can be no larger than 1/6th of the minimum raise amount.
* **Performance package configuration:** after the ICO, 10M tokens go to sale participants and 2.9M tokens go to liquidity. But you can also choose for up to 12.9M tokens to be pre-allocated to a performance package. This package is split up into 5 equal tranches, each of which unlock at 2x, 4x, 8x, 16x, and 32x the ICO price respectively. There’s also a minimum time at which insiders can start unlocking, which must be at least 18 months from ICO date but can be longer if you wish. The price is taken over a 3-month TWAP, which extends the true date at which an insider can receive tokens for 3 months beyond the minimum date they can start unlocking.
* **Example:** Alice pre-allocates 10M tokens to her project’s performance package with a minimum unlock time of 24 months out. The project raises \$1m, setting an ICO price of \$0.1 (1 million dollars divided by 10 million tokens). 24 months out, the token is trading 10x above the ICO price at \$1. Alice initiates the TWAP and the price stays at \$1 over 3 months. She then unlocks the first three tranches, equating to 6 million tokens. A year later the price is sitting at \$2 and she unlocks another 2 million tokens.
* **Intellectual property:** the list of intellectual properties that the founder(s) will give up to the project’s entity. This includes but is not limited to domain names, software, and social media accounts.
## The process
Today, you need to complete the [project intake form](https://metadao.typeform.com/to/DxVVAxhC) to get started. Expect to hear from MetaDAO co-founder [Kollan House](https://t.me/kollan_house) and if you haven't heard from us in two days reach out! [We’re working on automating this process right now](https://v1.metadao.fi/metadao/trade-v5/7XMU3qTYrXe3yccr4qCLEPvmENGmC22MyMKMX9zJAi9x).
You should also join the [Telegram channel](https://t.me/+QTv0A_WAjcRiZWQx) to stay up to date with the progress and process.
Once we've put you in our system, you'll show up on the site. You can then start the ICO whenever you want.
# The ICO
Source: https://docs.metadao.fi/how-launches-work/sale
How projects get funded
## Overview
*NOTE: We're still experimenting with different launch mechanisms and this
is all subject to change. If you have a novel idea or user feedback,
[reach out](https://t.me/metaproph3t).*
Investors get 4 days to commit USDC to a raise.
Sales have a **discretionary cap**, which means that the founder
can choose how much of the USDC committed goes to the project.
Allocations and refunds are based on how much money users commit
and how early their commitments are.
10M tokens are distributed proportionally among all participants.
## Why a discretionary cap?
The purpose of the discretionary cap is to allow believers to
participate while preventing projects from over-raising.
If you look at [other launch mechanisms](https://vitalik.eth.limo/general/2017/06/09/sales.html), they all have issues:
* Capped first-come-first-serve launches can be sniped
* Capped pro rata launches can be easily gamed - if you see a sale is
2x oversubscribed, you may put up 2x the USDC, which makes it
even more oversubscribed - which leads to poor UX for believers
* Uncapped sales are more likely to over-raise
* Dutch auctions are too complicated
## How do allocations work?
For most allocations, the basic idea is "the earlier you commit, and the more money you commit,
the more allocation you'll get."
For a more in-depth explanation:
* Your USDC grows an accumulator every second it stays committed: `accumulator += committed_amount × elapsed_seconds`.
* Your allocation share is proportional to your accumulator weight: `share = your_accumulator / total_accumulator`.
* On top of this, a **fill boost** multiplies the accumulator of funders who committed when the pool was still sparse — rewarding those who discovered the project early, not just those who committed early.
* Everyone pays the **same price per token** (same FDV). Committing earlier and when the pool is emptier means a higher accumulator — resulting in a **larger allocation** for the same commitment.
## Can funds and angels get guaranteed allocations?
Before a raise, founders and MetaDAO may discuss it with funds and larger
investors to solicit soft commits.
Founders can give guaranteed allocations to value-additive investors that they
want in the raise.
This process helps ensure that raises fill and that we bring quality to market.
## What happens when a sale is successful?
If a sale is successful, the following happens:
1. All USDC goes to a market-governed treasury.
2. The authority to mint new tokens is transferred to the treasury.
3. That treasury provides 20% of the USDC and 2.9M tokens to liquidity pools.
In effect the project will buy back tokens below the ICO price and sell them
above the ICO price.
The team can then spend their configured monthly budget out of the treasury.
To make larger spends or issue new tokens, they need to raise governance proposals.
## What happens when a sale fails to reach its minimum?
When a project fails to reach its minimum, everyone is refunded their USDC back.
## How are teams incentivized?
Teams can optionally decide to have some tokens
allocated to a price-based performance package.
This package is split into 5 equal tranches: one that unlocks at 2x ICO price,
one that unlocks at 4x ICO price, and so on for 8x, 16x, and 32x.
The minimum unlock time on these tranches is at least 18 months from ICO date
but can be extended by the founder.
Teams may also forego this route and instead figure out incentives later,
[as MetaDAO did](https://v1.metadao.fi/metadao/trade/BgHv9GutbnsXZLZQHqPL8BbGWwtcaRDWx82aeRMNmJbG).
# The Colosseum STAMP
Source: https://docs.metadao.fi/how-launches-work/stamp
Raising private capital before your MetaDAO ICO
## Overview
The **STAMP** (Simple Token Agreement, Market Protected) is an investment contract from [Colosseum](https://www.colosseum.com). It provides a clear path from private capital to a public MetaDAO ICO.
Get the STAMP document and learn more at Colosseum
## Why the STAMP Exists
Traditional crypto fundraising instruments like SAFEs + token warrants create dual equity + token structures that lead to:
* Confusion for tokenholders about where value accrues
* Potential extraction by insiders
* Unnecessary costs and complexity
The STAMP solves this by making the **token the sole economic unit** — governed, protected, and aligned via the MetaDAO protocol. Full motivation: [Colosseum's announcement](https://blog.colosseum.com/introducing-the-colosseum-stamp/).
## Who Is the STAMP For?
* **New startups:** Founders with no existing legal entity who want to raise seed capital before their ICO
* **Existing cap tables:** Founders with equity structures and existing investors who need to migrate to a token-only model
## How the STAMP Works
### For New Startups
1. **Set up entity**: Create a Cayman SPC/SP entity through the MetaDAO interface
2. **Sign STAMP**: Investor signs the STAMP and sends funds (typically stablecoins) to your wallet
3. **Use funds**: Funds can only be used for product development and operating expenses
4. **ICO occurs**: Remaining balance transfers to DAO-controlled treasury along with IP
5. **Token delivery**: Investors submit a Delivery Notice to receive their tokens
### For Existing Cap Tables
1. **Create entity**: Set up a Cayman SPC/SP entity
2. **Sign STAMP**: Any existing SAFE, note, or convertible is terminated and replaced
3. **Clean migration**: Private investors receive tokens as specified in previous agreements
4. **Market protection**: All tokenholders receive governance protections via MetaDAO
## Key Terms
### Investor Reserve
Each STAMP investor is allocated a **fixed portion** of the project's future token supply:
* Must be equal to or below **20%** of all project tokens
* Removes ambiguity and eliminates post-hoc renegotiation
* Provides predefined token entitlement that cannot be diluted
### Team Allocation
The STAMP specifies milestone-based team allocation:
* **Minimum**: 10% of total token supply
* **Maximum**: 40% of total token supply
Ensures adequate token share for ICO participants.
### Token Unlock
* Tokens enter a **24-month linear unlock** schedule once the Delivery Notice is received
* Aligns long-term incentives between investors and the project
## Benefits
### For Founders
| Benefit | Description |
| ----------------------- | -------------------------------------------------- |
| **Clean structure** | Single token-based ownership, no equity complexity |
| **Cap table migration** | Existing SAFEs/warrants cleanly convert |
| **Preserved autonomy** | Maintain control while ensuring transparency |
| **Cost-effective** | Simpler legal structure reduces costs |
### For Investors
| Benefit | Description |
| ---------------------- | ---------------------------------------------------------- |
| **Market protection** | MetaDAO's decision markets protect token value |
| **Clear entitlement** | Fixed token allocation, no ambiguity |
| **Onchain governance** | Real ownership over treasury and IP |
| **Rug protection** | ICOs on MetaDAO prevent rugs and allow fair capital return |
## Using the STAMP
1. Download the STAMP from [colosseum.com/stamp](https://www.colosseum.com/stamp)
2. Consult legal counsel in your jurisdiction
3. Customize the agreement for your startup
4. Proceed to [Getting Listed](/how-launches-work/create) for your MetaDAO ICO
## Resources
| Resource | Description |
| --------------------------------------------------------------------------------- | ----------------------------------- |
| [Colosseum STAMP Page](https://www.colosseum.com/stamp) | Official STAMP document and FAQ |
| [STAMP Announcement](https://blog.colosseum.com/introducing-the-colosseum-stamp/) | Full background and motivation |
| [Getting Listed](/how-launches-work/create) | Next steps for launching on MetaDAO |
| [The ICO](/how-launches-work/sale) | How the MetaDAO ICO works |
## Legal Notice
Colosseum does not assume responsibility for the contents of, or the consequences of using, drafts of the STAMP. Crypto founders and investors should consult with legal counsel in their countries before using this agreement.
# Welcome to MetaDAO
Source: https://docs.metadao.fi/index
A fundraising and governance platform for high-quality founders and their communities
## Community ownership matters
Projects grow faster when they have an army of bagholders supporting them:
[//]: # "TODO: add links on stablecoin market cap to DeFillama and developer count on electric report and faster and cheaper"
[//]: # "- Ethereum did an ICO for 85% of its supply. It remains dominant on metrics like stablecoin market cap and
developer count despite Solana being 10x faster and 1000x cheaper."
* Hyperliquid distributed 33% of its supply to its users. [Its perp volume 6xed](https://defillama.com/protocol/perps/hyperliquid).
* Yearn distributed 100% of its supply to its early users. [It subsequently rose from an \$8M TVL project
to a \$6B TVL project without incentives.](https://defillama.com/protocol/yearn)
* MegaETH sold tokens in an Echo round to 2,900 people. [Its Kaito mindshare 15xed.](https://x.com/sandraaleow/status/1889658182458597445)
![]()
The above graph shows Hyperliquid volume over time. Can you see the point at which they launched a token?
## But most tokens are done poorly
There are many problems with the standard playbook for doing a token. These include:
* **Rampant insider dealings have led to a loss of trust**: hidden OTC deals, special insider payouts from the foundation, and the like have made many investors wary of tokens.
* **The tokens themselves have very little fundamental value**: because there aren't any legal protections, nothing stops revenue from flowing to the team or a labs entity.
* **Frontloaded demand and backloaded supply contribute to structurally lower prices over time**: because they generally launch at a high FDV and most of their
supply is vested over 2-3 years, these tokens need a large amount of incremental buy pressure to maintain their prices.
[Felipe Montealegre](https://twitter.com/TheiaResearch), a liquid token investor, describes these problems and others in his talk:
## MetaDAO is for founders who want to launch a token the right way
MetaDAO's core principles are:
* **Fair launch early**: instead of launching at a high FDV, projects launch early with high-float ICOs so that they can grow over time.
* **Real ownership and unruggability**: the most important parts of the project -
the intellectual property, the funds, and the ability to mint new tokens - are controlled by [market-driven governance](/governance/overview).
This imbues the token with value and mitigates the risk of malicious teams rugging the treasury.
* **Pay-for-performance**: insiders unlocks are proportional to the premium over the launch price. This keeps teams and participants aligned.
While much of crypto concerns itself with how to maximally extract value over the short-term, MetaDAO is built from the
ground up for long-term founders and their communities.
# MiCA White Paper
Source: https://docs.metadao.fi/mica
META Token MiCA white paper — Digital Token Identifier BQ53DH590
Official META Token white paper for crypto-assets other than asset-referenced tokens or e-money tokens.
Portable PDF copy for reading and sharing
Original Inline XBRL filing format
| Field | Value |
| --------------------------------------------- | ------------------------------------ |
| Digital Token Identifier | `BQ53DH590` |
| Offeror / person seeking admission to trading | `254900XHQIYLONV5P484` — MetaDAO LLC |
| Type of submission | New |
Use the page table of contents to jump between parts. For the authoritative filing formats, use the PDF or XBRL links above.
## General information
| Item | Value |
| ----------------------- | ---------- |
| 01 Date of notification | 2026-07-02 |
### 02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
### 03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
### 04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114
The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.
| Item | Value |
| ------------------------------------------------------------------------------------- | -------------- |
| 05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 | Not applicable |
### 06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114
The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
## SUMMARY
### 07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114
This summary should be read as an introduction to the crypto-asset white paper.
The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.
The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
### 08 Characteristics of the crypto-asset
The crypto-asset referred to in this white paper is the META Token ("Token"). The Token is the governance token of MetaDAO ("DAO"), a decentralized community developing the MetaDAO Protocol ("Protocol"), which is accessible through the MetaDAO platform ("Platform").
The Protocol is a META-Token powered governance infrastructure that organizes the DAO's governance through market-based "futarchy" mechanisms. Under this model, governance decisions are driven by Token holders providing price signals rather than conventional token-holder voting (see Section D.04 below for further information).
The Token does not represent nor confer any ownership, equity interest, participation, corporate governance rights, or any rights beyond the programmatic functionalities expressly described herein, nor any entitlement to business revenues, profit sharing, or other similar economic benefits in relation to the Platform, the Company, or any other entity or individual.
| Item | Value |
| ------------------------------------------- | ---------------------------------------- |
| 09 Further information about utility tokens | Not applicable, as 05 is not applicable. |
### 10 Key information about the offer to the public or admission to trading
MetaDAO LLC ("Company"), a company incorporated and domiciled in Marshall Islands, seeks admission of the Token on trading platforms operating within the European Union ("EU") and/or the European Economic Area ("EEA") ("Trading Platforms").
## Part A — Offeror / person seeking admission to trading
| Item | Value |
| ------------------------------------------------------------------- | ----------------------------------------------------- |
| A.1 Name | MetaDAO LLC |
| A.2 Legal form | See A.06 |
| A.3 Registered address | See A.06 |
| A.4 Head office | See A.06 |
| A.5 Registration date | 2024-02-16 |
| A.6 Legal entity identifier | `254900XHQIYLONV5P484` |
| A.7 Another identifier required pursuant to applicable national law | Not applicable. See A.06. |
| A.8 Contact telephone number | +1 (925) 269-7135 |
| A.9 E-mail address | [technology@metadao.fi](mailto:technology@metadao.fi) |
| A.10 Response time (days) | 7 |
| A.11 Parent company | Not applicable. |
### A.12 Members of the management body
| Item | Value |
| ---------------- | --------------------------------------------------------------------------------------------------------- |
| Identity | Robin Van Niekerk |
| Business address | Trust Company Complex, Ajeltake Road, Ajeltake Island, Majuro, Republic of the Marshall Islands, MH 96960 |
| Function | Authorized Representative Nominee |
### A.13 Business activity
The Company's purpose is to develop Solana-based products and services, as well as such other activities as may be determined through the Protocol's futarchy-based governance mechanisms.
| Item | Value |
| ------------------------------------------------- | ------------------------- |
| A.14 Parent company business activity | Not applicable. See A.11. |
| A.15 Newly established | true |
| A.16 Financial condition for the past three years | Not applicable. See A.15. |
### A.17 Financial condition since registration
#### Financial aspect
| Item | Value |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Initial capital contribution | The Company was established with an initial capital of USDC 10,000 in accordance with the laws of Marshall Islands. A capital increase of 13,000,000 was carried out in 3 years, and no further increases are currently anticipated as of the date of this notification. |
| Source of funds | The Company generates funding through its commercial activities, as described in the purpose set out in Section A.13. |
| Revenue | Since incorporation through 03/31/2026: \$3,405,744 |
| Expenses | Since incorporation through 03/31/2026: \$4,046,704 excluding gross revenue tax. |
| Liabilities and financial commitments | The Company has no outstanding liabilities, debts, or financial commitments and does not face any financial risks or uncertainties impacting its long-term sustainability. |
#### Non-financial aspect
The Platform has facilitated the raising of 40M+ for other businesses via the Protocol.
## Part B — Issuer (if different)
The issuer is the same as the offeror / person seeking admission to trading (MetaDAO LLC). Fields B.2–B.12 are not applicable.
| Item | Value |
| ------------------------------------------------------------------------ | ----- |
| B.1 Issuer different from offeror or person seeking admission to trading | false |
## Part C — Trading platform operator / other drafters
Not applicable. This white paper is drawn up by the person seeking admission to trading (MetaDAO LLC), not by a trading-platform operator or another Article 6(1) drafter.
| Item | Value |
| -------- | ----- |
| C.1–C.14 | N/A |
## Part D — Token project
| Item | Value |
| ----------------------------- | ---------- |
| D.1 Crypto-asset project name | MetaDAO |
| D.2 Crypto-asset name | META Token |
| D.3 Abbreviation | \$META |
### D.4 Crypto-asset project description
MetaDAO Protocol – The Protocol is the first futarchy governance infrastructure, in which result of governance decisions is determined by market signals rather than conventional voting mechanisms. Under this model, DAO resolutions are reached through the following process:
* Creation of Proposals: DAO members can submit proposals, provided that they stake a specified amount of Tokens as required by the Protocol.
* Creation of Pass and Fail Markets: For each proposal, the Protocol establishes two corresponding markets: a "pass" market and a "fail" market.
* Creation of Conditional Tokens: DAO members may engage in these markets by minting conditional tokens through dedicated vault mechanisms, including pMETA (representing a "pass" outcome) and fMETA (representing a "fail" outcome).
* Creation of Market-Based Decision: In both the pass and fail markets, participants place bids and offers reflecting their expectations regarding the outcome of the proposal. For instance, a participant expecting that a proposal to be approved would purchase pMETA and sell fMETA, directly expressing that view through market activity.
Once the relevant governance decision-making period closes, the governance proposal's outcome is determined by a time-weighted average price (TWAP): a proposal passes only if the TWAP of the pass market exceeds that of the fail market. Accordingly, proposals are implemented where market participants collectively expect them to have a positive effect on the overall project.
**MetaDAO** — The DAO, comprising Token holders, governs all decisions relating to the Token supply, DAO's treasury expenditures, and matters concerning the Protocol's intellectual property.
**\$META** — The purpose of the Token is to enable Token holders to access the Protocol and participate in the DAO's governance. The Protocol and the Token are designed such that Token holders do not have any rights in relation to the Company's decision-making processes, including, for example, corporate governance decisions such as the election of board members or the approval of mergers and acquisitions.
### D.5 Persons involved in implementation of the crypto-asset project
| Item | Value |
| ------------------- | ------------------------------------------------------ |
| Type of person | Other person involved in implementation |
| Name | Organization Technology LLC |
| Business address | 500 3rd Street Suite 535, San Francisco, CA 94017, USA |
| Domicile of company | United States of America |
| Item | Value |
| ---------------------------------------------------------------- | ------------------------- |
| D.6 Utility token classification | false |
| D.7 Key features of goods or services for utility token projects | Not applicable. See D.06. |
### D.8 Plans for the token
#### Past milestones
* Public Testnet of the Platform: November 2023
* Token Generation Event: November 2023
* Public Airdrop: November 2023
* Public Token Sale: None
#### Future milestones
Admission on Trading Platforms operating within the EU / EEA: The date has not yet been determined, but in any case, it will take place only after the publication of the white paper (see F.09).
### D.9 Resource allocation
The Company has completed financing rounds totaling USDC 13.1 million by October 2025.
The financial resources have been primarily allocated to human and technical resources for the development, operation, and expansion of the Protocol, as well as the Platform. This includes financing core engineering, infrastructure provisioning, and ongoing security audits. Additional funds may be directed towards ecosystem growth initiatives, such as supporting developers and educational efforts to expand community participation.
| Item | Value |
| --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| D.10 Planned use of collected funds or other tokens | Not applicable. The Company is seeking admission to trading and does not collect any funds in that context. |
## Part E — Offer to the public / admission to trading
| Item | Value |
| ------------------------------------------- | -------------------- |
| E.1 Public offering or admission to trading | Admission to trading |
### E.2 Reasons for public offer or admission to trading
The Token serves as the governance token of the DAO. The admission of the Token to trading aims to make it accessible among potential DAO participants, enabling them to fully engage with and benefit from the Protocol and the Platform.
**E.3–E.11 (fundraising / issue price):** Not applicable. This white paper relates solely to admission to trading under Article 5 of MiCA and does not relate to a public offering.
| Item | Value |
| --------------------------------------------------- | ---------------------- |
| E.12 Total number of offered or traded other tokens | 22,684,698 |
| E.13 Targeted holders | All types of investors |
### E.14 Holder restrictions
Trading Platforms, in accordance with applicable laws and their internal policies, may impose restrictions on Token buyers and sellers. These may include, among others, the successful completion of Know Your Customer (KYC) procedures, Anti-Money Laundering (AML) checks, and measures to combat the financing of terrorism (CFT).
| Item | Value |
| ---------------------------------------------------------------- | ------------------------------------------- |
| E.15 Reimbursement notice | N/A |
| E.16 Refund mechanism | Not applicable. See explanation under E.03. |
| E.17 Refund timeline | Not applicable. See explanation under E.03. |
| E.18 Offer phases | Not applicable. See explanation under E.03. |
| E.19 Early purchase discount | Not applicable. |
| E.20 Time-limited offer | N/A |
| E.21 Subscription period beginning | N/A |
| E.22 Subscription period end | N/A |
| E.23 Safeguarding arrangements for offered funds or other tokens | Not applicable. See explanation under E.03. |
### E.24 Payment methods for other token purchase
The method of payment to buy and sell the Token on the Trading Platform is determined and set by the Trading Platforms and is not controlled, influenced, or governed by the Company.
| Item | Value |
| --------------------------------------------- | ------------------------------------------- |
| E.25 Value transfer methods for reimbursement | Not applicable. See explanation under E.03. |
| E.26 Right of withdrawal | Not applicable. See explanation under E.03. |
### E.27 Transfer of purchased other tokens
The purchased Tokens can be transferred to or from the purchaser's compatible wallet or technical device as designated by the Trading Platforms. The Company bears no responsibility for any transfers of the Token between buyers and sellers conducted on the Trading Platforms.
### E.28 Transfer time schedule
The transfer of the Token from the seller's wallet or device to the buyer's wallet or device may not occur immediately. The Company has no control over the timing of such transfers.
### E.29 Purchaser's technical requirements
Token holder must comply with the technical requirements specific to the Trading Platforms on which the Token is admitted to trading, which may include the following:
* A compatible digital wallet or account on supported Trading Platforms
* Internet access
| Item | Value |
| --------------------------------------------- | --------------- |
| E.30 Other token service provider (CASP) name | Not applicable. |
| E.31 CASP identifier | N/A |
| E.32 Placement form | Not applicable |
### E.33 Trading platforms name
Admission to trading is or might be sought on different Trading Platforms operating within the EU/EEA, including Kraken, Bitstamp, OKX, or MiCA CASP such as Coinbase.
Users should check their own Trading Platforms to see if the Token is supported.
### E.34 Trading platforms market identifier code (MIC)
| Platform | MIC |
| -------- | ---- |
| Kraken | PESL |
| Bitstamp | BESA |
| Item | Value |
| ----------------------------- | -------------------------------------------------------------------------------------------------- |
| E.35 Trading platforms access | Trading Platforms are accessible via their respective websites or applications for mobile devices. |
### E.36 Involved costs
The use of services offered by Trading Platforms may involve costs, including transaction fees, withdrawal fees, and other charges, which should be notified to users in advance. These costs are determined and set by the respective Trading Platforms and are not controlled, influenced, or governed by the Company.
| Item | Value |
| -------------------------- | ------------------------------------------- |
| E.37 Offer expenses | Not applicable. See explanation under E.03. |
| E.38 Conflicts of interest | Not applicable. |
### E.39 Applicable law
Seeking admission to trading of the Token shall be governed by the laws and regulations of the Republic of the Marshall Islands, where the Company, as the person seeking admission to trading is incorporated, as well as the European Union law, including Regulation (EU) 2023/1114 on Markets in Crypto-Assets (MiCAR) together with any mandatory provisions of applicable national laws of the respective Member States (to the extent the latter do not contradict mandatory provisions of EU law).
Once the Tokens are trading, the legal relationship and applicable law between the Trading Platforms and their users shall be determined on the basis of the law governing the contract between them and the applicable mandatory provisions of EU law.
Nothing in this whitepaper shall deprive any consumer located in the EU or EEA of the mandatory rights conferred on that consumer by the consumer-protection legislation of his or her country of habitual residence, if applicable.
### E.40 Competent court
The courts of the Republic of the Marshall Islands constitute a proper and convenient forum for disputes, claims or proceedings related to the person seeking admission to trading as it is incorporated in that jurisdiction.
Any disputes arising in connection with the seeking of admission to trading of the Token that are between the Company and the respective Trading Platform for crypto-assets shall be determined by the respective competent court depending on the contractual arrangement (if any) between the parties and the mandatory provisions of applicable law.
The competent court for any disputes between Trading Platforms and their users shall be determined on the basis of the contract between them and the applicable EU law.
If you are an EU or EEA consumer, you may bring any judicial proceedings before the competent court of your place of residence.
## Part F — Token information
| Item | Value |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| F.1 Crypto-asset type | Crypto-asset other than e-money tokens and asset-referenced tokens |
| F.2 Other token functionality | The purpose of the Token is to enable Token holders to interact with the Protocol and participate in the DAO's governance |
| F.3 Planned application of functionalities | While further functionalities may be introduced in the future, there is no commitment or guarantee that such functionalities will be implemented |
| F.4 Type of crypto-asset white paper | Other crypto-asset token white paper |
| F.5 Type of submission | New |
| F.6 Other token characteristics | The purpose of the Token is to enable Token holders to interact with the Protocol and participate in the DAO's governance |
| F.7 Commercial name or trading name | See F.13 |
| F.8 Website of the issuer | [docs.metadao.fi/mica](https://docs.metadao.fi/mica) |
| F.9 Starting date of offer to the public or admission to trading | N/A |
| F.10 Publication date | 2026-07-31 |
| F.11 Any other services provided by the issuer | None |
| F.12 Language or languages of white paper | English |
| F.13 Digital token identifier | `BQ53DH590` |
| F.14 Functionally fungible group digital token identifier | `JTCV65M2F` |
| F.15 Voluntary data flag | false |
| F.16 Personal data flag | true |
| F.17 LEI eligibility | true |
| F.18 Home member state | Ireland |
| F.19 Host member states | Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden |
## Part G — Rights and obligations
### G.1 Purchaser rights and obligations
The Token does not confer any rights or entitlements to its holders. Instead, the Token solely provides access to the Protocol and enables participation in the decentralized governance of the DAO.
| Item | Value |
| ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| G.2 Exercise of rights and obligations | Not applicable. |
| G.3 Conditions for modifications of rights and obligations | Not applicable. |
| G.4 Future public offers | At the time of the present notification, no such offers are currently planned. |
| G.5 Issuer retained other token | 22,811 |
| G.6 Utility token classification | false |
| G.7 Key features of goods or services utility tokens | Not applicable. See G.06. |
| G.8 Utility tokens redemption | Not applicable. See G.06. |
| G.9 Non-trading request | true |
| G.10 Other tokens purchase or sale modalities | Not applicable. See G.09. |
| G.11 Other tokens transfer restrictions | There are no restrictions on transfers other than those that may be required by Trading Platforms to comply with applicable law. |
| G.12 Supply adjustment protocols | false |
| G.13 Supply adjustment mechanisms | Not applicable. See G.12. |
| G.14 Token value protection schemes | false |
| G.15 Token value protection schemes description | Not applicable. See G.14. |
| G.16 Compensation schemes | false |
| G.17 Compensation schemes description | Not applicable. See G.16. |
### G.18 Applicable law
The Tokens do not give rise to obligations or direct rights enforceable against their issuer.
The Token is governed by the applicable laws and regulations of the Republic of the Marshall Islands where the Company is incorporated.
Nothing in this whitepaper shall deprive any consumer located in the European Union or European Economic Area of the mandatory rights conferred on that consumer by the consumer-protection legislation of his or her country of habitual residence, if applicable.
### G.19 Competent court
The courts of the Republic of the Marshall Islands constitute a proper and convenient forum for disputes, claims or proceedings related to the creation of the tokens as the Company is incorporated in that jurisdiction.
EU or EEA consumers may be able to bring any judicial proceedings before the competent court of their place of residence.
## Part H — Underlying technology
| Item | Value |
| --------------------------------------- | -------- |
| H.1 Distributed ledger technology (DLT) | See F.13 |
### H.2 Protocols and technical standards
* **Solana Program Library (SPL):** The Token adheres to the SPL token standard, the Solana blockchain's equivalent of ERC-20 used within the Ethereum blockchain. This standard ensures compatibility with Solana's ecosystem, including decentralized exchanges (DEXs), wallets, and decentralized applications (dApps).
* **Anchor v0.29.0:** Development framework for building Solana programs (smart contracts). See [anchor-lang.com/docs](https://www.anchor-lang.com/docs).
* **Solana Verified Builds with Security Text:** A self-adhered standard amongst the Solana ecosystem, whereby the code deployed can be matched to a version control system whereby any person may build and trust the source is the source. See [solana-verifiable-build](https://github.com/solana-foundation/solana-verifiable-build).
* **Squads Multisig:** Best practice for managing program deploys and upgrades to ensure no one individual has unilateral control over the protocol.
### H.3 Technology used
* **RPC:** Helius and Triton RPC providers for aggregating, indexing, and displaying historical and current Solana account state
* **APIs:** Internal and external APIs for data retrieval, storage, and display — a mixture of on-chain state and self-contained state enriching on-chain data
* **Cloud computing / infrastructure:** Infrastructure to operate data collection and display, as well as monitoring, alerting, and frontend access to the on-chain application (smart contract / program)
* **Vercel:** Frontend application hosting with direct access to the on-chain program and wallet interface; also provides DNS routing, geofencing, and DDoS protection
* **GitHub:** Version control system used to manage all applications developed for the Protocol, including CI/CD integrations for program deployment
* **Squads:** Multisig program used to deploy and manage programs as an operational security best practice
### H.4 Consensus mechanism
* **Proof of History (PoH):** A unique innovation of the Solana blockchain — PoH serves as a cryptographic timestamp that establishes a historical record of transactions. PoH optimizes transaction validation by enabling nodes to agree on the order and time of transactions without extensive communication overhead, allowing for high-speed processing.
* **Proof of Stake (PoS):** Solana's network operates on a PoS consensus mechanism, where validators are selected based on the number of SOL tokens staked. This mechanism enhances security, energy efficiency, and scalability by requiring validators to commit resources to participate in the network.
### H.5 Incentive mechanisms and applicable fees
Solana Blockchain
The Solana blockchain operates on a proof-of-stake model (see H.04) under which validators and delegators are incentivized through staking rewards derived from protocol issuance and transaction fees. Validators earn rewards for producing blocks and participating in consensus, while delegators receive a reward for indirectly participating in securing the network.
| Item | Value |
| ---------------------------------------- | ------------------------ |
| H.6 Use of distributed ledger technology | false |
| H.7 DLT functionality description | Not applicable. See H.06 |
| H.8 Audit | true |
### H.9 Audit outcome
Audits have been conducted in the past and security issues around permissions and account state, token validation and access, as well as around conditional validation have been identified and resolved.
Full audit reports: [metaDAOproject/programs/audits](https://github.com/metaDAOproject/programs/tree/develop/audits)
## Part I — Risks
### I.1 Offer-related risks
#### Listing Risk
The Company, its affiliates, directors, and officers shall not be held liable for any damages, losses, costs, fines, penalties, or expenses of any kind – whether or not reasonably foreseeable by the Company or the Token holder – that the Token holder may suffer, sustain, or incur in connection with, or as a result of, the Token not being listed on a Trading Platform.
#### General Contractual and Counterparty Risk
The Company does not operate, control, oversee, or manage the functioning of crypto-asset services providers as defined under MiCA ("CASP") operating within the EU/EEA and Trading Platforms (together with CASPs, the "Exchanges"), where the Token will be admitted for trading or listed.
#### Multiple White Paper Risk
Token holders understand that any third party can decide to draft and publish a MiCA white paper about the Token ("Spontaneous White Paper"). The publication of these Spontaneous White Papers does not imply any endorsement by the Company that the Spontaneous White Papers are complete, correct, fair, clear and not misleading.
#### Spontaneous Admission to Trading Risk by Trading Platform
Third parties can elect to admit the Token on their Trading Platforms without any request, authorization or approval by the Company or anyone else. Pursuant to article 5 (2) of MiCA, Trading Platforms are responsible for ensuring compliance with all applicable laws, especially MiCA requirements with respect to the spontaneous admission of the Token to trading. The Company, its affiliates, directors, agents and officers shall not be held liable for these spontaneous admissions to trading.
#### Exchanges Risk
When Token holders buy or sell Token on the Exchanges, the Company does not serve as a contractual party or counterparty to the transaction. Consequently, any legal relationship concerning these Exchanges is subject to their own terms and conditions. The Company, and its service providers, assume no responsibility for the operations, services, or outcomes associated with any transactions or activity on the Exchanges. The Company makes no representations or warranties regarding any Exchange itself and disclaims all responsibility or liability for any regulatory, compliance, operational, financial, technical, or reputational failures that may adversely affect its activities.
#### Pausing and Delisting Risk
The Company cannot and does not guarantee that the Token will remain listed or tradeable on any of the Exchanges. Delisting (or the temporary pausing of such listing) on any of the Exchanges could significantly hinder the ability of Token holders to buy, sell, or otherwise transact in Token. In the event of delisting, Token holders may face challenges in finding alternative markets or counterparties willing to trade or transact in the Token, which could impact on the liquidity and market value of Token. The Company, its affiliates, directors, agents and officers shall not be held liable for any losses or damage arising from the suspension, removal, or delisting of the Token from any Exchange.
#### Trading Risk
The Company does not control the secondary markets. There can be no representations nor warranties as to the secondary market (if any) in Token. It cannot and does not guarantee the depth, stability, or sustainability of any secondary market for Token. Limited market depth or trading activity may result in reduced liquidity, increased price volatility, and challenges in buying or selling the Token at desired prices. The Company also cannot and does not guarantee the healthy and consistent availability of buying or selling opportunities for the Token or the integrity of the market price. Trading activity may be affected by manipulative practices such as wash trading, front-running, and similar schemes. While Exchanges and other Trading Platforms may be subject to varying regulatory frameworks that may or may not prohibit such practices and impose oversight to detect and deter them, the Company assumes no responsibility or liability for their effective prevention or enforcement.
#### Operational and Technical Risk
The Exchanges operate interfaces that allow users to trade crypto-assets for or other crypto-assets. The reliance on any Exchanges' internal system for asset storage and transfer adds an additional layer of counterparty risk, as users are exposed to potential operational, technical, or human errors during these processes, including the following:
* Trades on an Exchange may be executed based on a centralized matching algorithm and are often recorded off-chain, meaning they are not directly related to transparent on-chain transfers of crypto-assets, and could dissimulate detrimental trade matching or rogue practices. The traded assets are recorded solely on the Exchange's internal ledger, with each internal ledger entry corresponding to an offsetting trade involving either government currency or another crypto-asset.
* Funds deposited by users for trading may be comingled by the Exchanges, rather than stored in unique wallet addresses for each user. This practice results in the centralization of a large volume of assets in a single location, which in turn increases the potential risk of damage or theft, particularly in the event of a hack or security breach.
* Furthermore, users who wish to trade or withdraw their Token may be required to deposit them into the Exchange, increasing the risk of loss in the event of a failure of the deposit or withdrawal Token processes set up by an Exchange.
#### Unanticipated Risks
In addition to the risks outlined in this Section, unforeseen risks may arise. Additionally, new risks could emerge as unexpected variations or combinations of the risks discussed in these Sections I.01 to I.05.
### I.2 Issuer-related risks
The person seeking admission to trading, i.e., the Company is simultaneously the entity controlling the technical minting of the Token. As such, the person seeking admission to trading qualifies as the issuer within the meaning of article (3) (1) (10) of MiCA. Given that the issuer and the person seeking admission are the same entity, and for the sake of consistency, statements related to the issuer shall be deemed as statements related to the person seeking admission, i.e., the Company.
#### Abandonment/Lack of Success Risk
The Protocol and related activities may be partially or totally abandoned for several reasons including, but not limited to, the lack of interest from the public, incapacitation or withdrawal of Token key developers and project supporters, force majeure (including pandemics and wars) or lack of commercial success or prospects.
#### Change Risk
The Protocol may evolve over time. This could involve pivoting from the original vision of the Protocol or modifying how the vision and objectives are executed. Such changes may be driven by market conditions, regulatory development, technological advancements, or strategic decisions by Protocol contributors. While adaptation and change can foster innovation, it also introduces risks, including shifts in value proposition and potential misalignment with prior expectations.
#### Partner Risk
The implementation of the Platform and Protocol depends strongly on the collaboration and functioning of services provided by several third parties, core contributors, activities of the legal entities associated with the project and other crucial ecosystem partners. Loss or changes in the project's leadership, key partners, and other service providers can lead to disruptions, loss of trust, reputational damage, or even complete project failure. The Company cannot and does not guarantee that the Platform and the Protocol will remain operational in perpetuity.
#### Legal and Regulatory Compliance Risk
Crypto-assets and blockchain technologies are subject to an evolving regulatory landscape worldwide. Regulations vary widely across jurisdiction and may be subject to significant changes, which would lead to changes with respect to the trading of the Token. Changes in laws or regulations may negatively impact on the value, legality, or functionality of the Token. Non-compliance with changing or newly formed regulations can result in investigations, enforcement actions, penalties, fines, sanctions, or the prohibition of trading of Token, impacting the Platform and/or Protocol's viability and market acceptance. The Company, core contributors, or other ecosystem partners could be subject to private litigation. Additionally, any legal uncertainties, potential lawsuits, or adverse legal rulings can pose significant risks to the project. Legal challenges may ultimately affect the legality, usability, or value of the Token.
#### Reputational Risk
There could be a risk of negative publicity related to the Platform and/or the Protocol and its affiliated legal entities, whether due, without limitation to operational failures, security breaches, or association with illicit activities, all of which can damage the ecosystem reputation and, by extension, the value and usability of the Token.
#### Operational Risk
Any failure to develop or maintain effective internal control or any difficulties encountered in the implementation of such controls could harm the operations of the Company, causing disruptions, financial losses, or reputational damage.
#### Competition Risk
Similar crypto-assets projects may enter the market at any time. The effect of existing, new or additional competition on the Token or its market price cannot be predicted or quantified. Competitors may have significantly greater financial, legal, and technical resources than the Company and there is no guarantee that the project will be able to compete successfully, or at all, with such competitors.
#### Unanticipated Risks
In addition to the risks outlined in this Section, unforeseen risks may arise. Additionally, new risks could emerge as unexpected variations or combinations of the risks discussed in these Sections I.01 to I.05.
### I.3 Other tokens-related risks
#### Market Risk
Crypto-assets, including the Token, are highly volatile, with prices subject to significant fluctuations in short periods due to market sentiment, regulatory news, technological advancements, and macroeconomic factors, which increases the risk of sudden and substantial losses. Such valuation risk arises as the market value of a crypto-asset may not always reflect its underlying utility or fundamentals and is subject to subjective assessment. Potential Token holders are thus exposed to potential losses due to the Token's:
* Potential fluctuations in value, driven by various factors such as supply and demand dynamics, Token purchasers' and holders' sentiment, and broader market trends, including changes in interest rates, general movements in local and international markets, technological advancements, regulatory changes, and media coverage. Notably, momentum pricing of crypto-assets has previously resulted, and may continue to result, in speculation regarding future appreciation or depreciation in the value of such assets, further contributing to volatility and potentially inflating prices at any given time.
* Liquidity risk, where a lack of depth in secondary markets – if any – or limited trading volumes can hinder the ability to execute trades at favorable prices, which could lead to significant losses, especially in fast-moving market conditions. As a result, Token holders may experience challenges in managing their holdings, with the value of the asset subject to unpredictable fluctuations and potential depreciation.
* Solvency and collateral risk, if the Token is used to finance further activities, especially in leveraged positions or as collateral for loans. Significant fluctuations in the value of the Token could adversely affect the solvency of its holder, particularly if the Token is pledged as collateral. A drastic decline may trigger margin calls or automatic liquidations, which could further depress Token's price creating a negative feedback loop. This volatility poses the risk of forced asset sales, potentially resulting in substantial losses for the holder and amplifying downward pressure on the market price of the Token.
#### Custodial Risk
The method chosen to store the Token, like any crypto-asset, carries inherent risks related to the security and management of the storage solution. The chosen storage method – whether hot or cold wallets, or centralized custody – can significantly impact the safety, liquidity, and accessibility of the Token, with direct consequences for the holder's ability to access, trade, or retain their assets.
#### Scam Risk
Token holders may be subject to the risk of loss resulting from a scam or fraudulent schemes perpetrated by malicious actors targeting Token holders. These scams include, but are not limited to, phishing or social engineering on social Platforms or by email, fake giveaways, identity theft or impersonation of key contributors to the Platform, creation of fake Tokens, offering fake Token airdrops, among others. Token holders, recipients and purchasers should always verify and confirm that they are interfacing with legitimate websites, personnel, and other assets associated with the Platform.
#### Anti-Money Laundering / Counter-Terrorism Financing (AML/CTF) Risk
Crypto-asset wallets holding Token or transactions in Token may be used for money laundering or terrorist financing purposes or attributed to a person or entity known to have committed or is associated with such offenses. Consequently, there is a risk that a public wallet address holding Token could be flagged in relation to AML/CTF efforts. In such cases, receiving Tokens could result in a holder's address being flagged by relevant authorities, Exchanges, or other service providers, which may lead to restrictions on transaction or the freezing of a holder's assets. Token holders may thus face legal or regulatory challenges if their address becomes associated with illicit activities, impacting their ability to freely access, trade, or transfer their tokens.
#### Taxation Risk
The taxation regime that applies to the trading of Tokens by either individual holders or legal entities will depend on each Token holder's jurisdiction. The Company cannot and does not guarantee that the holding of the Token, the receipt of the Token, conversion of fiat currency against the Token, or other conversion of other crypto assets against the Token, will not incur tax consequences. It is the Token holder's sole responsibility to comply with all applicable tax laws, including, but not limited to, the reporting and payment of income tax, wealth tax, capital gains tax, or other similar taxes arising in connection with the appreciation and depreciation of the Token.
#### Market Abuse Risk
The market for crypto-assets is rapidly evolving, spanning local, national, and international Platforms with an expanding range of assets and participants. Any market abuse, along with a potential loss of confidence among holders, could adversely impact the value and stability of the Token. Notably:
* Significant trading activity may take place on systems and Platforms with limited oversight and predictability. Sudden and rapid changes in the supply or demand of a crypto-asset, particularly those with low market capitalization or low unit prices, can result in extreme price volatility.
* Additionally, the inherent characteristics of crypto-assets and their underlying infrastructure may be exploited by certain market participants to engage in abusive trading practices such as front-running, spoofing, pump-and-dump schemes, and fraud across different Platforms, systems, or jurisdictions.
#### Legal and Regulatory Risk
There is a lack of regulatory harmonization globally, which results in diverging regulatory frameworks. Regulations related to crypto-assets remain in flux globally with possible further regulatory evolution in the future. Divergent and shifting regulation could negatively impact the value, utility and overall viability of the Token. Specifically:
* While Token is characterized as a token used to access and interact with the Platform, certain non-EU regulators may nevertheless classify the Token as a security, financial instrument, or payment instrument under their respective legal frameworks. Such classifications could impose specific regulatory constraints, leading to significant changes in how the Token is structured, purchased, or traded.
* Evolving regulations could substantially increase compliance costs and operational burdens relating to facilitating transactions in the Token.
* New or restrictive regulations could result in Token losing functionality, depreciating in value, or even becoming illegal or impossible to use, buy or sell in certain jurisdictions.
* Regulators could take enforcement action against the Company, if they determine that the Token constitutes a regulated instrument that has been issued in a non-compliant manner or that the activities of the project, its core contributors or other ecosystem partners violate existing laws. Such actions could expose such parties to legal and financial penalties, including civil and criminal liability.
#### Unanticipated Risks
In addition to the risks outlined in this Section, unforeseen risks may arise. Additionally, new risks could emerge as unexpected variations or combinations of the risks discussed in these Sections I.01 to I.05.
### I.4 Project implementation-related risks
#### Novel Ecosystem Risk
The Protocol, the Platform and its ecosystem are built on emerging and rapidly evolving technologies, which inherently carry significant risks. The underlying software, blockchain infrastructure, smart contracts, and related technologies are still in their early stages of development, meaning there is no guarantee that the process of receiving, using or holding the Token will be uninterrupted or error-free. As with any novel technology stack, there is an inherent risk that the underlying blockchain, smart contracts, novel technical features, or associated components may contain weaknesses, vulnerabilities, or bugs, despite audits being conducted. Such issues could lead to unintended behaviors, security breaches, or critical failures, potentially resulting in the partial or complete loss of the Token or their functionality or the inability to access or use the services of the Platform and/or the Protocol. Furthermore, unforeseen technical limitations, incompatibilities, or the emergence of superior alternatives could further impact the stability, security, and long-term success and viability of the Platform and/or Protocol ecosystem.
#### Dependency Risk
The Platform and the Protocol rely on third-party technologies, infrastructures, which could impact its functionality, security, and long-term sustainability. Any disruptions, vulnerabilities, regulatory scrutiny or changes in the Platform or the Protocol may result in a negative effect on the Token. This reliance on external infrastructure increases systemic risk, as unforeseen issues in third-party infrastructure could cascade into disruptions in the ecosystem.
#### Reliability Risk
There is a risk that the key features and services of the Platform and of the Protocol may not always function properly, negatively affecting the community's perception of the Platform and the Protocol and its underlying technology and in turn, affecting the value of the Token. The Platform and the Protocol will be deployed strictly on an "as is" and "as available" basis without any representations, warranties or guarantees of any kind, whether express or implied. The Company cannot and does not warrant that the Token, the software code of the Token, or the Platform are reliable current or error-free, free of viruses or other harmful components.
#### Unanticipated Risks
In addition to the risks outlined in this Section, unforeseen risks may arise. Additionally, new risks could emerge as unexpected variations or combinations of the risks discussed in these Sections I.01 to I.05.
### I.5 Technology-related risks
The person seeking admission to trading and its affiliate, directors, agents and officers shall not be responsible or liable for any damages, losses, costs, fines, penalties or expenses of whatever nature, whether reasonably foreseeable by them and the potential Token holder, and which the Token holder, may suffer, sustain, or incur, arising out of or relating to the technical risks outlined below or a combination thereof.
#### Cybersecurity Risk
The Token - including the Protocol and the Platform infrastructure, underlying technology such as smart contracts, wallets and other components - may be vulnerable to cyberattacks. Malicious actors may exploit software vulnerabilities, attack consensus mechanisms, or compromise private keys to gain unauthorized access to the Token. Risks include hacking attempts on the Protocol, the Platform, smart contract exploits, phishing attacks, malware infections, and other forms of cybercrime that could result in the theft, loss, or unauthorized transfer of the Token. Since digital assets exist entirely in a technological environment, they are inherently exposed to evolving cyber threats, some of which may be undetectable or irreparable until after significant damage has occurred.
#### Smart Contract Risk
Transactions associated with the Token rely on smart contracts deployed on a Solana. Smart contracts are susceptible to coding vulnerabilities, bugs, or security flaws that could be exploited by malicious actors. A breach in the smart contract could result in unauthorized transactions, token loss, or manipulation of staking mechanism, negatively impacting the Token's security and trust among Token holders. Even though independent security audits are routinely conducted, unforeseen vulnerabilities may still pose a risk.
#### Private Key Management Risk and Loss of Access to Crypto-Assets
The security of the Token holding heavily relies on the management of private keys, which are used to access and control crypto-assets. The Token holders are responsible for the custody of their Tokens in a compatible cryptographic wallet and for the security of their private keys. Poor management practices, loss, or theft of private keys, or respective credential, can lead to irreversible loss of access to the Tokens. If a Token holder connects their wallet to malicious applications or Platforms, they also risk unauthorized access to their assets and their Token holdings.
#### Protocol and Platform-Level Risk
It cannot be excluded that any technical failure, malfunction, or vulnerability within the Protocol or the Platform could directly or indirectly impact the value of the Token.
* The Protocol and the Platform could be subject to critical exploits, such as reentrancy attacks, logic errors, or oracle manipulation, which could lead to unintended token transfers, assets being drained from the system, or tokens being irretrievably lost. Fixing such issues may require significant coordination, governance approval, or even disruptive measures such as migrations or forks, none of which are guaranteed to be successful.
* Any security breach, or governance deadlock affecting the Protocol or the Platform could have cascading effects, including depreciation of the Token's value, reduced market confidence, and potential loss of funds for Token holders.
* Settlement Finality and Irrevocability of Transactions: Transactions in Token may be irreversible. Holders sending Tokens to nonexistent or incorrect addresses may irrevocably lose their Tokens and be unable to reverse the transaction or recover their Tokens.
#### Unanticipated Risks
In addition to the risks outlined in this Section, unforeseen risks may arise. Additionally, new risks could emerge as unexpected variations or combinations of the risks discussed in these Sections I.01 to I.05.
### I.6 Mitigation measures
While security audits have been conducted (see H.09), potential Token holders understand that the risks outlined in Sections I.01 to I.05 above are inherent to the Protocol and Platform activities and its broader ecosystem, making elimination impossible.
## Part J — Sustainability indicators
### J.1 Adverse impacts on climate and other environment-related adverse impacts
The below is information on the principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism used to validate and finalize transactions in the Tokens and to maintain the integrity of the distributed ledger of transactions.
The energy consumption for the validation and finality of transactions and the maintenance of the integrity of the distributed ledger of transactions for the period is estimated to be lower than 500,000 kWh (see S.08).
### General information about adverse impacts
| Item | Value |
| -------------------------------------------------------------- | ---------------------- |
| S.1 Name | MetaDAO LLC |
| S.2 Relevant legal entity identifier | `254900XHQIYLONV5P484` |
| S.3 Name of the crypto-asset | META |
| S.4 Consensus mechanism | See H.04. |
| S.5 Incentive mechanisms and applicable fees | See H.05. |
| S.6 Beginning of period to which disclosed information relates | 2025-01-01 |
| S.7 End of period to which disclosed information relates | 2025-12-31 |
### Mandatory key indicator
| Item | Value |
| ---------------------- | ------------- |
| S.8 Energy consumption | 23,840.30 kWh |
### S.9 Energy consumption sources and methodologies
The estimated energy consumption in S.08 was calculated using the methodology recommended by the Crypto Carbon Ratings Institute in its December 2024 Paper, version 2.0 "Methodologies to calculate sustainability indicators for the EU Markets in Crypto-Assets (MiCA) regulation", available at [carbon-ratings.com](https://carbon-ratings.com/dl/whitepaper-mica-methods-2024).
### Supplementary key indicators
| Item | Value |
| ------------------------------------------- | --------------- |
| S.10 Renewable energy consumption | 0% |
| S.11 Energy intensity | 0 |
| S.12 Scope 1 DLT GHG emissions - controlled | 0 |
| S.13 Scope 2 DLT GHG emissions - purchased | 0 |
| S.14 GHG intensity | 0 |
| S.15 Key energy sources and methodologies | Not applicable. |
| S.16 Key GHG sources and methodologies | Not applicable. |
### Optional indicators
| Item | Value |
| ------------------------------------------------------------------- | --------------- |
| S.17 Energy mix | 0% |
| S.18 Energy use reduction | N/A |
| Energy use reduction target (absolute value) | 0 |
| Energy use reduction target (percentage) | 0% |
| S.19 Carbon intensity (kgCO2e/kWh) | 0 |
| S.20 Scope 3 DLT GHG emissions - value chain | 0 |
| S.21 GHG emissions reduction targets or commitments | Not applicable. |
| S.22 Generation of waste electrical and electronic equipment (WEEE) | 0 |
| S.23 Non-recycled WEEE ratio | 0% |
| S.24 Generation of hazardous waste | 0 |
| S.25 Generation of waste (all types) | 0 |
| S.26 Non-recycled waste ratio (all types) | 0% |
| S.27 Waste intensity (all types) | 0 |
| S.28 Waste reduction targets or commitments (all types) | Not applicable. |
| S.29 Impact of use of equipment on natural resources | Not applicable. |
| S.30 Natural resources use reduction targets or commitments | Not applicable. |
| S.31 Water use | 0 |
| S.32 Non-recycled water ratio | 0% |
| S.33 Other energy sources and methodologies | Not applicable. |
| S.34 Other GHG sources and methodologies | Not applicable. |
| S.35 Waste sources and methodologies | Not applicable. |
| S.36 Natural resources sources and methodologies | Not applicable. |
# Protocol Analytics & Resources
Source: https://docs.metadao.fi/protocol/analytics
External analytics, transparency dashboards, and protocol metrics for MetaDAO
## Overview
MetaDAO is committed to transparency and open access to protocol data. This page provides links to external analytics platforms, transparency dashboards, and resources for monitoring protocol activity.
## Analytics Platforms
Comprehensive analytics for MetaDAO's Futarchy AMM including volume, revenue, and trader metrics
Protocol TVL, historical data, and cross-chain comparisons
### Blockworks Research
[Blockworks Analytics](https://blockworks.com/analytics/metadao/metadao-futarchy-amm) provides detailed metrics on MetaDAO's Futarchy AMM:
* **Volume by Token**: Trading volume grouped by DAO launched on MetaDAO
* **Protocol Revenue**: Revenue generated from the 0.25% trade fee
* **New Pools Launched**: DAOs launched using Futarchy AMM
* **Unique Traders**: Trader activity grouped by DAO
### DeFiLlama
[DeFiLlama](https://defillama.com/protocol/metadao) tracks MetaDAO's protocol metrics including:
* Total Value Locked (TVL)
* Historical TVL charts
* Protocol rankings and comparisons
## Transparency & Reporting
Token transparency standards and reporting
Official MetaDAO transparency dashboard
### Token Transparency
MetaDAO is committed to meeting high standards of token transparency. [Blockworks Token Transparency](https://blockworks.co/token-transparency) provides industry standards for token reporting and disclosure.
### Onchain Verification
All protocol activity is verifiable onchain:
| Resource | Description |
| -------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| [Solana Explorer](https://explorer.solana.com/address/METAwkXcqyXKy1AtsSgJ8JiUHwGCafnZL38n3vYmeta) | View META token supply and transactions |
| [Proposal History](https://v1.metadao.fi) | Browse all past governance proposals |
| [MetaDAO App](https://metadao.fi) | Official governance and trading interface |
## Developer Resources
Open source Solana programs powering MetaDAO's futarchy governance
Access real-time supply data, pricing, and protocol metrics
### Program Addresses
All MetaDAO programs are deployed on Solana mainnet and are fully open source. View the source code at [github.com/metaDAOproject/programs](https://github.com/metaDAOproject/programs).
#### Current Programs (v0.7.0)
| Program | Version | Address | Explorer |
| --------- | ------- | --------------------------------------------- | --------------------------------------------------------------------------------------- |
| Launchpad | v0.7.0 | `moontUzsdepotRGe5xsfip7vLPTJnVuafqdUWexVnPM` | [View](https://explorer.solana.com/address/moontUzsdepotRGe5xsfip7vLPTJnVuafqdUWexVnPM) |
| Bid Wall | v0.7.0 | `WALL8ucBuUyL46QYxwYJjidaFYhdvxUFrgvBxPshERx` | [View](https://explorer.solana.com/address/WALL8ucBuUyL46QYxwYJjidaFYhdvxUFrgvBxPshERx) |
#### Current Programs (v0.6.0)
| Program | Version | Address | Explorer |
| ------------------- | ------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Futarchy | v0.6.0 | `FUTARELBfJfQ8RDGhg1wdhddq1odMAJUePHFuBYfUxKq` | [View](https://explorer.solana.com/address/FUTARELBfJfQ8RDGhg1wdhddq1odMAJUePHFuBYfUxKq) |
| Launchpad | v0.6.0 | `MooNyh4CBUYEKyXVnjGYQ8mEiJDpGvJMdvrZx1iGeHV` | [View](https://explorer.solana.com/address/MooNyh4CBUYEKyXVnjGYQ8mEiJDpGvJMdvrZx1iGeHV) |
| Performance Package | v0.6.0 | `pbPPQH7jyKoSLu8QYs3rSY3YkDRXEBojKbTgnUg7NDS` | [View](https://explorer.solana.com/address/pbPPQH7jyKoSLu8QYs3rSY3YkDRXEBojKbTgnUg7NDS) |
#### Active Programs (v0.5.0 / v0.4)
| Program | Version | Address | Explorer |
| ----------------- | ------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Launchpad | v0.5.0 | `mooNhciQJi1LqHDmse2JPic2NqG2PXCanbE3ZYzP3qA` | [View](https://explorer.solana.com/address/mooNhciQJi1LqHDmse2JPic2NqG2PXCanbE3ZYzP3qA) |
| Autocrat | v0.5.0 | `auToUr3CQza3D4qreT6Std2MTomfzvrEeCC5qh7ivW5` | [View](https://explorer.solana.com/address/auToUr3CQza3D4qreT6Std2MTomfzvrEeCC5qh7ivW5) |
| AMM | v0.5.0 | `AMMJdEiCCa8mdugg6JPF7gFirmmxisTfDJoSNSUi5zDJ` | [View](https://explorer.solana.com/address/AMMJdEiCCa8mdugg6JPF7gFirmmxisTfDJoSNSUi5zDJ) |
| Conditional Vault | v0.4 | `VLTX1ishMBbcX3rdBWGssxawAo1Q2X2qxYFYqiGodVg` | [View](https://explorer.solana.com/address/VLTX1ishMBbcX3rdBWGssxawAo1Q2X2qxYFYqiGodVg) |
#### Intermediate Versions
| Program | Version | Address | Explorer |
| --------- | ------------------------ | ---------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Launchpad | delayed-twap-v0.4.1 | `AfJJJ5UqxhBKoE3grkKAZZsoXDE9kncbMKvqSHGsCNrE` | [View](https://explorer.solana.com/address/AfJJJ5UqxhBKoE3grkKAZZsoXDE9kncbMKvqSHGsCNrE) |
| Autocrat | proposal-duration-v0.4.2 | `autowMzCbM29YXMgVG3T62Hkgo7RcyrvgQQkd54fDQL` | [View](https://explorer.solana.com/address/autowMzCbM29YXMgVG3T62Hkgo7RcyrvgQQkd54fDQL) |
| AMM | delayed-twap-v0.4.1 | `AMMyu265tkBpRW21iGQxKGLaves3gKm2JcMUqfXNSpqD` | [View](https://explorer.solana.com/address/AMMyu265tkBpRW21iGQxKGLaves3gKm2JcMUqfXNSpqD) |
#### Legacy Programs (v0.3 and earlier)
| Program | Version | Address | Explorer |
| ----------------- | ------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Autocrat | v0.3 | `autoQP9RmUNkzzKRXsMkWicDVZ3h29vvyMDcAYjCxxg` | [View](https://explorer.solana.com/address/autoQP9RmUNkzzKRXsMkWicDVZ3h29vvyMDcAYjCxxg) |
| AMM | v0.3 | `AMM5G2nxuKUwCLRYTW7qqEwuoqCtNSjtbipwEmm2g8bH` | [View](https://explorer.solana.com/address/AMM5G2nxuKUwCLRYTW7qqEwuoqCtNSjtbipwEmm2g8bH) |
| Conditional Vault | v0.3 | `VAU1T7S5UuEHmMvXtXMVmpEoQtZ2ya7eRb7gcN47wDp` | [View](https://explorer.solana.com/address/VAU1T7S5UuEHmMvXtXMVmpEoQtZ2ya7eRb7gcN47wDp) |
| Autocrat v0 | v0.2 | `metaRK9dUBnrAdZN6uUDKvxBVKW5pyCbPVmLtUZwtBp` | [View](https://explorer.solana.com/address/metaRK9dUBnrAdZN6uUDKvxBVKW5pyCbPVmLtUZwtBp) |
| Autocrat Migrator | v0.2 | `MigRDW6uxyNMDBD8fX2njCRyJC4YZk2Rx9pDUZiAESt` | [View](https://explorer.solana.com/address/MigRDW6uxyNMDBD8fX2njCRyJC4YZk2Rx9pDUZiAESt) |
| Conditional Vault | v0.2 | `vAuLTQjV5AZx5f3UgE75wcnkxnQowWxThn1hGjfCVwP` | [View](https://explorer.solana.com/address/vAuLTQjV5AZx5f3UgE75wcnkxnQowWxThn1hGjfCVwP) |
| Autocrat v0 | v0.1 | `metaX99LHn3A7Gr7VAcCfXhpfocvpMpqQ3eyp3PGUUq` | [View](https://explorer.solana.com/address/metaX99LHn3A7Gr7VAcCfXhpfocvpMpqQ3eyp3PGUUq) |
| Autocrat Migrator | v0.1 | `migkwAXrXFN34voCYQUhFQBXZJjHrWnpEXbSGTqZdB3` | [View](https://explorer.solana.com/address/migkwAXrXFN34voCYQUhFQBXZJjHrWnpEXbSGTqZdB3) |
| Autocrat v0 | v0 | `meta3cxKzFBmWYgCVozmvCQAS3y9b3fGxrG9HkHL7Wi` | [View](https://explorer.solana.com/address/meta3cxKzFBmWYgCVozmvCQAS3y9b3fGxrG9HkHL7Wi) |
| Conditional Vault | v0 | `vaU1tVLj8RFk7mNj1BxqgAsMKKaL8UvEUHvU3tdbZPe` | [View](https://explorer.solana.com/address/vaU1tVLj8RFk7mNj1BxqgAsMKKaL8UvEUHvU3tdbZPe) |
For the latest updates and source code, see the [Programs README](https://github.com/metaDAOproject/programs#readme) on GitHub.
Supply, tickers, and health data are available programmatically. Use Solana RPC for supply ([see token details](/token/details)); for REST endpoints and full reference, see [api-docs.metadao.fi](https://api-docs.metadao.fi/introduction).
## Protocol Metrics
### Key Stats
MetaDAO provides real-time metrics through various channels:
* **Trading Volume**: Available via [Blockworks Analytics](https://blockworks.com/analytics/metadao/metadao-futarchy-amm)
* **TVL**: Available via [DeFiLlama](https://defillama.com/protocol/metadao)
* **Supply Data**: Available via [API](https://api-docs.metadao.fi/introduction) and [Solana Explorer](https://explorer.solana.com/address/METAwkXcqyXKy1AtsSgJ8JiUHwGCafnZL38n3vYmeta)
### Revenue Model
The protocol generates revenue through:
* **0.25% trade fee** on all Futarchy AMM trades
* Fees are distributed according to governance decisions
## External Links
| Resource | URL | Description |
| ---------------------- | ------------------------------------------------------------------------------------------------- | --------------------------- |
| MetaDAO App | [metadao.fi](https://metadao.fi) | Main application |
| Transparency Dashboard | [metadao.fi/transparency](https://metadao.fi/transparency) | Official transparency page |
| GitHub Programs | [github.com/metaDAOproject/programs](https://github.com/metaDAOproject/programs) | Open source Solana programs |
| API Documentation | [api-docs.metadao.fi](https://api-docs.metadao.fi/introduction) | Developer API docs |
| Blockworks Analytics | [blockworks.com/analytics/metadao](https://blockworks.com/analytics/metadao/metadao-futarchy-amm) | Protocol analytics |
| DeFiLlama | [defillama.com/protocol/metadao](https://defillama.com/protocol/metadao) | TVL tracking |
| Token Transparency | [blockworks.co/token-transparency](https://blockworks.co/token-transparency) | Transparency standards |
| Legacy Interface | [v1.metadao.fi](https://v1.metadao.fi) | Proposal history |
## Questions?
For questions about protocol analytics or data access, please contact the MetaDAO team through our official channels or join our community.
# META Token Details
Source: https://docs.metadao.fi/token/details
Tokenomics, supply information, and issuance mechanisms for the META token
## Overview
META is the governance and utility token of the MetaDAO protocol. This page covers supply, distribution, and issuance.
## Token Migration
**Active Migration**: MetaDAO is migrating from legacy METAC to META. If you hold METAC, please migrate.
Migration portal — no fees, one-way
| Token | Mint Address | Status |
| ------------------ | --------------------------------------------- | ------------ |
| **META** (New) | `METAwkXcqyXKy1AtsSgJ8JiUHwGCafnZL38n3vYmeta` | ✅ Active |
| **METAC** (Legacy) | `METADDFL6wWMWEoKTFJwcThTbUmtarRJZjRpzUvkxhr` | ⚠️ Migrating |
* No fees. One-way. Migrate in batches if needed. Verify receipt in your wallet after migration.
Migration contract: [github.com/metaDAOproject/token-migrator](https://github.com/metaDAOproject/token-migrator), NPM `@metaDAOproject/token-migrator`
## Supply Information
**META Mint Address:** `METAwkXcqyXKy1AtsSgJ8JiUHwGCafnZL38n3vYmeta`
View live supply under "Current Supply"
### Fetch Supply via JSON-RPC
Query any Solana RPC with `getTokenSupply`:
```bash theme={null}
curl https://api.mainnet-beta.solana.com \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getTokenSupply","params":["METAwkXcqyXKy1AtsSgJ8JiUHwGCafnZL38n3vYmeta"]}'
```
For REST endpoints and full API docs, see [api-docs.metadao.fi](https://api-docs.metadao.fi/introduction).
### Maximum Supply
**No Hard Cap**: META has no token-program-level cap. Mint authority is governance-controlled, not a human operator. Supply increases only via governance-approved proposals.
* No hard cap enforced by the token contract
* All issuance must be proposed and pass futarchy
* No silent or discretionary minting
### Initial Distribution
* 10M tokens at launch, fair launch mechanism
* No private sales or insider allocations at launch
## Issuance Mechanism
New META tokens are minted only through governance:
1. **Proposal** — Anyone can create one
2. **Stake** — 200,000 tokens (2%) staked for proposal to go live
3. **Markets** — 3-day conditional trading period
4. **Execution** — If traders judge issuance will increase value, tokens are minted
Lifecycle, timelocks, fund flows: [Token Mechanics](/token/mechanics)
**Governance controls:** Market-based approval, transparent onchain process, no unilateral minting.
## Regulatory Compliance
Real-time supply via API. Changes occur only through governance proposals.
Proposals visible before trading. 3-day period for market reaction.
No automatic inflation, scheduled unlocks, or vesting outside governance. All supply changes require market approval.
## Questions?
Contact the MetaDAO team through official channels.
# Token Mechanics
Source: https://docs.metadao.fi/token/mechanics
Detailed explanation of token minting, proposal execution, and onchain fund flows
## Overview
How META tokens are minted, the proposal lifecycle, and onchain fund flows.
## Proposal Lifecycle
### Stage 1: Proposal Creation
Anyone can create a proposal that includes token minting. When a proposal is created:
1. The proposal is published onchain with all details publicly visible
2. The proposal specifies:
* Number of tokens to mint (if any)
* Recipient address for minted tokens
* Purpose and rationale
**Public Visibility**: All supply-increasing proposals are publicly announced the moment they are created onchain. There are no private or hidden proposals.
### Stage 2: Stake Accumulation
Before a proposal can go live for trading:
* **200,000 tokens** (2% of initial 10M supply) must be staked on the proposal
* Staking is permissionless - any token holder can stake
* Stakes are returned after proposal is live for trading (no lockup or slashing risk)
* This prevents spam proposals from consuming governance resources
### Stage 3: Conditional Market Trading (3 Days)
Once sufficient stake is accumulated:
1. **Markets Open**: The project moves half its spot liquidity into conditional markets
2. **Trading Period**: Traders have **3 full days** to trade in pass/fail markets
3. **Price Discovery**: The market determines whether the proposal will increase or decrease token value
4. **Public Information**: All trading activity is visible onchain in real-time
**Investor Reaction Time**: The 3-day trading period ensures investors have sufficient time to evaluate supply-increasing proposals and react before any new tokens enter circulation.
### Stage 4: Resolution & Execution
After the 3-day trading period, the proposal is finalized using a **TWAP-based mechanism**:
**TWAP Finalization**: Pass/fail decisions use a Time-Weighted Average Price (TWAP) with a lagging design to reduce manipulation. This ensures the final decision reflects sustained market sentiment, not last-minute price spikes.
| Outcome | Condition | Result |
| -------- | ----------------------------------- | ----------------------------------- |
| **Pass** | Pass market TWAP > Fail market TWAP | Tokens minted, proposal executed |
| **Fail** | Fail market TWAP ≥ Pass market TWAP | No tokens minted, proposal rejected |
**Execution is automatic and immediate** - once the TWAP calculation determines the outcome, there is no additional timelock. The governance executor performs the onchain mint instruction to the proposal-specified destination.
## Timelock & Grace Periods
### Is There a Delay Between Approval and Minting?
**No Additional Timelock**: Once the 3-day trading period ends and the proposal passes, execution is immediate. The 3-day trading period itself serves as the grace period for investors to react.
The timeline for a token minting proposal:
```
Day 0: Proposal created (publicly visible)
↓
Day 0-X: Stake accumulation period (variable)
↓
Day X: Proposal goes live, markets open
↓
Day X+3: Trading period ends
↓
Day X+3: If passed, tokens minted immediately
```
### Pre-Vote Announcement
**Yes**, all supply-increasing proposals are formally announced before trading begins:
1. Proposal creation is an onchain transaction visible to all
2. The stake accumulation period provides additional notice
3. APIs and frontends display pending proposals
4. Social channels typically discuss significant proposals
## Inflation Structure
### Is META an Infinite Issuance Model?
**META is not hard-capped at the token-program level.** In SPL tokens, a "hard cap" only exists if mint authority is permanently removed and cannot be re-established.
In the current model:
* No hard cap is enforced by the token contract itself (so "infinite issuance" is possible in principle)
* But issuance is **gated by governance** and must be publicly proposed and pass the futarchy mechanism before execution
* The mint authority is the governance program — **not a human operator**
* There is no "silent" or off-chain discretionary minting
| Aspect | Description |
| ----------------------- | ----------------------------------------------------- |
| **Hard Cap** | None at protocol level |
| **Scheduled Inflation** | None - no automatic token emissions |
| **Minting Authority** | Governance program only - not a human operator |
| **Dilution Protection** | Market-based - proposals that harm value are rejected |
### Why No Hard Cap?
The governance-controlled model provides flexibility while maintaining accountability:
1. **Operational Funding**: Projects may need to fund development, marketing, or operations
2. **Ecosystem Growth**: Token incentives can attract users and liquidity
3. **Market Discipline**: The futarchy system rejects proposals that would dilute value unfairly
The absence of a hard cap is offset by the requirement that all minting must be approved by market participants who have capital at risk.
## Onchain Fund Flow
### Where Do Minted Tokens Go?
When tokens are minted through a proposal, they are sent to an address specified **in the proposal itself**:
The proposal creator defines the recipient address when creating the proposal. This could be:
* A specific wallet address
* A smart contract (e.g., vesting contract)
* The project treasury
* A multi-sig wallet
The recipient address is visible onchain from the moment the proposal is created. Anyone can verify where tokens will go before trading.
Upon proposal passage, tokens are minted directly to the specified address. There is no intermediate custody contract.
### Is the Recipient Address Fixed or Dynamic?
**Dynamic per Proposal**: Each proposal specifies its own recipient address. There is no single fixed address that receives all minted tokens.
This means:
* Different proposals can send tokens to different addresses
* Investors can evaluate the recipient as part of their trading decision
* Full transparency on the destination of all minted tokens
### Onchain Flow Diagram
```
┌─────────────────────────────────────────────────────────────┐
│ PROPOSAL CREATED │
│ • Defines: mint amount, recipient address, purpose │
│ • Publicly visible onchain │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ STAKE ACCUMULATION │
│ • 200,000 tokens staked (no lockup risk) │
│ • Variable duration │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ CONDITIONAL MARKETS (3 DAYS) │
│ • Pass market: "value if proposal passes" │
│ • Fail market: "value if proposal fails" │
│ • All trades visible onchain │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ TWAP-BASED FINALIZATION │
│ Pass TWAP > Fail TWAP? │
│ ├─ YES → Governance executor mints to recipient │
│ └─ NO → No tokens minted, proposal rejected │
└─────────────────────────────────────────────────────────────┘
```
Supply verification and JSON-RPC fetch: [Token Details](/token/details).