A prediction-market prototype that shares trading fees with creators and promoters

The problem

Oracl's thesis: prediction markets pay the platform and the traders. The person who writes a good question gets no lasting, trustless share of the fees. The person who shares the question and brings traders in gets none either.

Oracl wanted to pay both people automatically, from the trades they bring. To take the idea to investors, Oracl needed a product investors could click through and a contract design in which the fee split works.

What we built

We split the contracts into three parts. A factory creates each market and is the only contract that can resolve it. Each market prices and executes its own trades. A token contract holds the YES and NO positions as ERC-1155 tokens, backed by USDC.

A promoter's link carries the promoter's wallet address, and the address goes straight into the trade call. In the same transaction, the market takes its fee and divides it between the market's creator, the promoter, a liquidity pool and the treasury. If a trade has no promoter, or the creator promotes the trade, the promoter's share goes to the treasury. The contract needs no referral database, and nothing has to match referrals to trades afterward.

We let each fee share build up as a balance, and its owner withdraws it. This costs every creator and promoter one more transaction, on each market, to collect their money. In return, a trade never sends funds to an outside address. That keeps the trade simpler. It also removes a common way to attack a contract mid-transaction.

The investor app had to be ready before any contract was deployed, so we built it against a simulated backend. Every screen exists: browsing markets, trading, creating a market, positions, and the creator, promoter and admin views. The app connects wallets for real, on the Base Sepolia testnet. Trades go to the simulation, and the app calls no Oracl contract. The simulation sits behind the app's own API routes. A real backend can replace the simulation without changing a screen.

What was hard

LMSR prices a binary market from the shares sold on each side. Its formula uses logarithms and exponents, and Solidity has only whole numbers, so the contract prices with approximations. The contract rewrites the formula in a form that stays stable with large numbers. It approximates the logarithm. It runs a binary search of up to 64 steps to find how many shares a given amount of USDC buys.

The approximation does not match exact LMSR pricing. The contract's own review note marks the approximation as safer for solvency but unfair to traders. The approximation is one of the parts to replace before the contracts hold funds.

The app had a related problem: prices had to move with no real traders. A server timer moves every active market's price every 250 milliseconds. The updates reach the browser as server-sent events. The app groups the updates, so a burst of them redraws the screen once. The price preview and the simulated buys use the same TypeScript LMSR code, so both price a trade by the same rules.

The result

The prototype proved that creator and promoter fees can be part of the trade. The contract attributes a referral and divides the fee inside the trade, with no attribution database. The app let an investor try the whole journey, from creating a market to claiming fees.

No one has deployed or audited the contracts. The review notes in the contract source list what to fix before the contracts hold funds:

• The fee-split constants pay the wrong percentages.
• Refunds on a voided market fail.
• No function withdraws the liquidity pool's share.
• A market can be resolved before its deadline.
• The tests assert an older fee than the contract charges.