Fidena turns football questions into on-chain prediction markets. Traders buy or sell YES and NO shares, with an LMSR market maker translating those trades into an implied probability.
The order ticket shows the cost and price impact before a trade. Positions can be sold back to the market, including while a match is in play.
The problem
A prediction market needs both a way to trade and a credible way to decide the result. A football question can sound simple while hiding ambiguity: which fixture, which statistic, which period, and who gets to declare the outcome? A permissionless creation flow is not useful if it can produce markets that the oracle cannot settle.
Fidena connects those two parts. It restricts questions to supported football data, uses a continuously available pricing curve for YES and NO shares, and requires oracle-verified evidence before a market can resolve.
Prices that express a probability
The market maker uses the Logarithmic Market Scoring Rule, or LMSR. Buying YES moves its price upward; buying NO moves it in the opposite direction. The two prices sum to one, making the current price an implied probability rather than a fixed betting odd.
The creator funds the curve with an initial subsidy of b × ln(2), where b controls liquidity. That subsidy bounds the market maker’s theoretical worst-case loss. A trader can review the quoted cost, fee, and price impact before buying, or sell shares back to the curve while the market is open, including during a match.
A question the oracle can answer
The creation flow draws fixtures and supported statistics from TxLINE. A creator selects the match and a predicate—such as total goals exceeding a threshold—then supplies the initial subsidy. This binds the market to a question the integrated oracle knows how to validate.
Predicates can combine two team statistics through addition or subtraction. Total goals can use the sum of both teams’ goals; a team-to-win question can compare their difference. The fixture and predicate become part of the market rather than an interpretation left for an operator after the match.
Resolution with a proof
A TypeScript keeper watches open markets for full-time, fetches the stat-validation proof, and submits settlement. The Pinocchio program makes a cross-program call to TxLINE’s oracle, which checks the statistic against a daily scores root using a Merkle proof. Invalid or missing evidence leaves the market open.
Once resolved, the pricing curve stops and winning shares redeem for one test USDT each from the vault. The dashboard links the result to its settlement transaction. The keeper delivers evidence; it does not choose the winner. The trust boundary still includes the oracle’s published data and the upgradeable devnet programs.
Implementation and validation
The implementation spans fixed-point LMSR arithmetic in a Rust Pinocchio program, create/trade/redeem/settle instructions, an automatic settlement keeper, and a Next.js dashboard using Solana Kit and Wallet Standard. Prices, positions, and portfolio P&L are read from on-chain accounts.
The repository includes Mollusk tests for the transaction lifecycle and negative cases, alongside reference vectors for the pricing math and settlement predicates. The current scope is a World Cup-focused devnet prototype, not a mainnet service or a claim of production-scale usage.
Details
Solana, Rust, Pinocchio, Next.js, Solana Kit, TxLINE, TypeScript
Solana devnet prototype. The demonstration uses test funds.