Overview
A founder publishes a Raise Memo and fixed terms. Backers commit USDC during a fixed window. If the raise clears its minimum, one transaction launches the project: a token, protocol-owned liquidity, and a treasury that no person controls. The founder draws a streamed operating budget. Everything else (milestone tranches, transfers, mints, buybacks, config changes, even winding the project down) is a proposal, and each proposal is settled by a pair of decision markets.
Contracts are immutable. Nobody, Moneta included, can change a project's rules after its raise, move its funds, or pause its markets.
Raises
| Rule | What happens |
|---|---|
| One price | Every backer pays the founder's fixed price per token. FDV follows from it; it is never set separately. |
| Below the minimum | Every contribution is refunded in full. No fee is taken. |
| Above the maximum | Contributions keep flowing until the window closes. Each backer is allocated contribution × max ÷ total, and the excess is refunded. |
| Fixed window | Raises never close early at the maximum, so late backers aren't disadvantaged. |
| Finalize | Anyone can finalize once the window ends. A keeper does it within seconds. |
| Exit guarantee | If a raise still isn't finalized after its grace period, anyone can abort it and refunds open. Funds can't be trapped. |
| Claims | Tokens and refunds are pulled by each backer, so one blocked address can't hold up anyone else. |
Launch
Finalizing a successful raise does all of this atomically. If any step fails, the whole launch rolls back and the escrow is untouched.
accepted = min(total, max) fee = accepted × raise fee → protocol net = accepted − fee → treasury liquidity = net × liquidity share paired with new tokens at the raise price tranche_i = treasury at launch × bps_i fixed in USDC at launch
The spot pool opens at exactly the raise price, owned by the treasury. Its trading fees accrue to the treasury as the only liquidity provider.
Treasury
USDC can leave a treasury in only these ways:
| Path | Who triggers it |
|---|---|
| Streamed budget | The founder claims what has accrued, per second, since the last claim. |
| Passed proposal | Tranche release, transfer, buyback or arbitrary call, executed automatically after a PASS verdict. |
| Bond refund | A proposer's bond is returned when their proposal passes. On FAIL the treasury keeps it. |
| Redemption | After a passed redemption, holders burn tokens for a fixed pro-rata share. |
One proposal is live per project at a time, so proposals can't double-spend the treasury or move each other's prices. The one exception is a redemption, which can queue behind the live proposal and blocks new proposals until it has had its verdict.
Verdicts
Each proposal moves part of the spot liquidity into two pools that open at the same price: PASS-{TOKEN} against PASS-USDC, and FAIL-{TOKEN} against FAIL-USDC. The PASS pool prices the token in the world where the proposal executes. The FAIL pool prices it in the world where it doesn't.
Each pool keeps a lagging observation that moves toward the pool's spot price by at most a fixed step per second. The verdict compares time-weighted averages of those observations over the trading window, after a warm-up.
observation(t) moves toward spot at ≤ maxStep per second TWAP = ∫ observation dt over [tradingStart, tradingEnd] ÷ duration
PASS ⇔ twapPass × 10,000 ≥ twapFail × (10,000 + threshold)
Moving a verdict means holding a pool's price away from fair value for much of the window. The step cap limits how fast the observation can follow, and every arbitrageur profits by pushing it back. A last-second pump barely registers.
Anyone can finalize once the window ends. Finalizing resolves the markets, returns the winning side's liquidity to the spot pool, settles the bond, and executes the action. If execution reverts, the verdict still stands, and anyone can retry until the execution grace period ends.
Trading a verdict
Buying PASS with 10 USDC splits it into 10 PASS-USDC and 10 FAIL-USDC, then swaps the PASS-USDC for PASS-{TOKEN}. If the proposal passes, your PASS-{TOKEN} redeems 1:1 for the token. If it fails, your FAIL-USDC redeems 1:1 for USDC and you get your 10 USDC back. A bet in one world never risks your stake in the other.
Selling reverses it and merges matched pairs back into USDC. After the verdict, one click redeems every winning position. Losing positions are worth nothing.
Redemption
If holders believe the treasury is worth more returned than spent, anyone can propose a redemption. If it passes, the budget stops, liquidity is pulled, treasury-held tokens are burned, and the remaining USDC is fixed against the token supply. Each holder then burns tokens for exactly their share. Claim order doesn't matter.
Performance package
Founders can earn extra tokens only by creating value: each tranche mints once the spot TWAP holds at a multiple of the raise price (2×, 4×, 8×…) over an unlock window, after a cliff. Nothing is minted at launch.
Architecture
Every dollar sits in contracts. Each project gets its own escrow and treasury, deployed as minimal clones. The AMM, the conditional vault and the router are shared singletons. An indexer serves lists and history. Every gate and amount you act on is read straight from the chain.
| Contract | Role | Monad Testnet |
|---|---|---|
| MonetaFactory | Registry and protocol config. Creates raises; launches projects from successful ones as deterministic clones. | ↗ |
| Raise | One escrow per raise: contributions, finalize (launch or fail), claims and refunds. | ↗ |
| ProjectToken | ERC-20 with EIP-2612 permit. Only its treasury can mint. | ↗ |
| Treasury | Per-project custody and futarchy engine: proposals, verdicts, typed actions, budget, tranches, redemption. | ↗ |
| ConditionalVault | Splits collateral into PASS and FAIL tokens, then pays out the winning side after the verdict. | ↗ |
| MonetaAMM | Constant-product pools with a built-in lagging TWAP oracle. Treasury-owned liquidity only. | ↗ |
| MonetaRouter | Stateless helper: buy or sell a verdict, merge, redeem, spot swaps. Holds nothing between transactions. | ↗ |
Monad produces a block every 300 ms and finalizes in about 600 ms. Block timestamps have one-second granularity, so oracles update at most once per second. Monad charges the gas limit rather than gas used, so every Moneta transaction is simulated first and sent with a limit of 1.15× its estimate.
Security
| Guarantee | How |
|---|---|
| No upgrades | Every contract is immutable. New versions ship as a new factory; existing projects keep the rules they launched with. |
| Admin can't touch funds | The protocol Safe can allowlist quote assets, set fees within hard caps, set bounds for new raises, and pause new raise creation. Nothing else. |
| No trading pause | There is deliberately no swap pause. An admin who could freeze markets mid-window could swing a verdict. |
| Exits always open | Refunds, claims, merges, conditional redemptions and NAV redemptions can't be blocked. |
| Trusted spenders | Conditional tokens let only the AMM and router move them, and both only ever pull from the caller. |
| Isolated custody | Each raise and each treasury is its own contract. A problem in one project can't reach another's funds. |
Known external risks: Circle can freeze USDC for specific addresses, and an arbitrary-call proposal does exactly what its calldata says once the market passes it. Read the memo and the decoded action before trading.
Live state of the deployment: Protocol status →