Meridian

Demo

About

The problem it solves Prediction markets have proven that skin-in-the-game produces better decisions than voting the stock market identified the cause of the Challenger disaster in hours while the official investigation took months. Futarchy proposed using this power for governance: vote on values, bet on beliefs. But traditional prediction markets fragment liquidity across separate YES/NO pools for each outcome. Every new proposal thins the pool further, making markets easier to manipulate and less informative. This is why futarchy never shipped. Meridian solves the liquidity fragmentation problem by putting all competing proposals into a single unified pool, priced through LMSR (Logarithmic Market Scoring Rule) implemented as a Uniswap V4 hook. Users deposit once and that capital backs every proposal simultaneously. When the settlement window closes, the market collapses to the highest-amplitude proposal, and the winning strategy executes on-chain. **What people can use it for:** - **DAO governance** - Instead of token-weighted voting, communities can run quantum decision markets where proposals compete in a single pool. Capital-backed conviction replaces popularity contests. The winning proposal executes automatically. - **Treasury allocation** - A DAO asks "how should we allocate this quarter's treasury?" Multiple strategies compete in one market. Participants trade on which allocation will maximize the chosen metric. The market converges and executes. - **Agent-driven strategy selection** - Autonomous agents can propose, evaluate, and trade on competing strategies without human intervention. The agent generates proposals via AI inference, trades based on amplitude analysis, and executes the winning outcome. - **Parameter tuning** - Protocols can use decision markets to set parameters (fee tiers, collateral ratios, emission rates) through market-based consensus rather than multisig decisions. The key improvement over existing prediction markets: liquidity scales with the pool, not per-proposal. Adding a fifth proposal to a market does not split the depth five ways. It shares the same pool as the first four. Use of AI tools and agents Meridian's autonomous agent uses AI inference as its core reasoning layer for two critical functions: **proposal generation** and **trade signal computation**. Both run through [0G Compute Network](https://0g.ai/), a decentralized inference network. ### Proposal Generation When the agent discovers a market with no proposals, it generates one using AI: 1. The agent reads the market's question and metric type from the on-chain factory contract 2. It constructs a prompt with the market context (question, metric type, settlement window, existing proposals) 3. The prompt is sent to 0G Compute, targeting one of three models: - **Qwen 2.5 7B** - fast, general purpose - **GPT-OSS 20B** - deeper reasoning - **Gemma 3 27B** - strongest capability 4. The model returns a structured JSON with a proposal description, target metric value, and reasoning 5. The agent submits the proposal on-chain via the QuantumMarketFactory The AI is prompted to generate proposals that are specific, measurable, and tied to the market's metric type (predicted yield, token price, agent score, or custom). ### Trade Signal Computation Every 30 seconds, the agent evaluates open markets and decides whether to trade: 1. It reads current amplitudes (probabilities) for all proposals in a market 2. It reads its own position and remaining deposits 3. It sends this state to 0G Compute with a prompt asking for a trade signal 4. The model returns a JSON with: which proposal to trade, direction (buy/sell), amount, and reasoning 5. The agent executes the trade through the Uniswap V4 hook ### Fallback Intelligence If 0G Compute is unavailable, the agent does not stop. It falls back to deterministic strategies: - **Proposal fallback**: Parses the market question with regex, matches against known metric types, and returns context-appropriate proposals (e.g., yield strategies for PREDICTED_YIELD markets, price targets for TOKEN_PRICE markets) - **Trade fallback**: Momentum strategy - buys the highest-amplitude proposal with a fixed size (0.1 WAD) ### Payment for Compute The agent settles inference costs through 0G's broker-based payment system. After each inference call, `processResponse()` is called to settle with the compute provider. The agent also earns revenue through x402 micropayments on its own API, creating a self-sustaining loop: external users pay the agent for services, and the agent uses that revenue to pay for AI inference. ### How the Components Work Together ``` External User/Agent | x402 payment ($0.01) | Meridian Agent API | +---------+---------+ | | 0G Compute Base Sepolia (AI inference) (on-chain execution) | | Proposal/Signal Factory/Hook/Registry | | +----> Agent executes trade on Uniswap V4 | Market collapses | Base Mainnet swap (ERC-8021 builder codes) | Kite AI payment log ``` The AI is not a chatbot or assistant. It is the agent's decision-making engine, it proposes strategies, evaluates markets, and drives autonomous trading. The agent reasons through markets the same way a human trader would, but at 30-second intervals with no downtime.

How it's made

Challenges we ran into **LMSR fixed-point math in Solidity.** The core pricing function `b * ln(sum(exp(q_i / b)))` requires exponentials and logarithms in WAD (1e18) fixed-point arithmetic. Solidity has no native floating point, so we built a fixed-point math library with 6th-degree rational approximations for `exp()` and 7-term series approximations for `ln()`. The main issue was accumulated rounding errors from cascading divisions. We had to clamp exponential inputs (overflow at `e^88 ~ 1.65e38`) and handle underflow at the lower bound to prevent zero-division in the logarithm. There are no formal error bounds on the approximation getting this right required extensive testing against known LMSR outputs. **Uniswap V4 hook state synchronization.** The `beforeSwap` hook intercepts trades and routes them through LMSR instead of the standard AMM curve. The tricky part: the hook must return a `BeforeSwapDelta` telling the PoolManager how much was consumed, but the actual cost comes from the LMSR calculation. If these diverge, the pool drains. We also had to disable standard `addLiquidity`/`removeLiquidity` entirely - all capital enters through a custom `deposit()` function because V4's native liquidity management doesn't understand LMSR positions. **Cross-chain coordination across four networks.** The agent operates across Base Sepolia (markets), Base mainnet (swaps), 0G Galileo (compute + identity), and Kite AI testnet (payments). Each chain has its own RPC client, wallet, and failure modes. Early on, the x402 payment middleware was registered on the wrong chain ID `eip155:8453` (Base mainnet) instead of `84532` (Base Sepolia) which silently failed every payment attempt. The environment variable was also misnamed (`X402_FACILITATOR` in `.env` vs `FACILITATOR_URL` in code). These bugs were invisible because the agent gracefully falls back to direct on-chain calls when x402 fails. **0G Compute inference reliability.** The 0G Compute SDK loads dynamically and can fail silently if the broker initialization races with the agent's monitoring loop. If the import fails once, the agent runs the entire session using deterministic fallbacks without ever retrying. We made the fallbacks context-aware - they parse the market question and metric type to generate relevant proposals instead of generic responses - but the lack of a retry mechanism means the agent may never use AI inference in a session where initialization fails. **ERC-7857 iNFT transfer deadlock.** The oracle-verified transfer protocol requires three steps: owner initiates, oracle approves, anyone executes. We discovered there is no timeout or cancellation mechanism. If the TEE oracle goes down after a transfer is initiated, the token is permanently stuck in a pending state. The owner cannot retract the transfer. This is a known limitation we plan to address with a timeout-based auto-cancel.