How it works

Markets and Launch

Two bearer-position venues, with different pricing, creation and settlement paths.

Markets and Launch share one privacy pattern: shielded value leaves the STRK20 pool for a venue, and the venue records a commitment instead of an owner address. The browser keeps the secret behind that commitment so the position can be cashed out, claimed, redeemed or refunded later.

That shared shape does not make them the same product. Markets settles a priced side against Pragma. Launch sells fixed units along an epoch staircase and ends in either a deployed token or a full refund. The contracts are deployed on Starknet mainnet; addresses and deploy transactions are in the evidence.

Bearer means the secret controls the position

The browser stores each position secret before it broadcasts the transaction. Keep the recovery backup while a position remains open. A commitment can be read publicly, but it cannot claim the position without its secret.

Markets architecture

Markets architecture from live contract and Pragma reads through a pool-funded bearer bet, oracle settlement and a payout note
Markets: the first bet can create a standing window; settlement or cash-out returns value through the pool. Click the image to expand it.

Open the Markets PNG.

1. The board is a live read surface

The client reads the current and previous window for every active series, recent custom markets, the idle house float, contract quotes and the public event tape. Pragma prices feed the cards and charts. TanStack Query owns those reads; the chain feed writes into the same cache, with RPC polling as the fallback.

An untouched standing window is not yet a stored market. Its id and deadline are derived from the series and the current epoch. The first valid bet opens it, takes a fresh Pragma median as the line and moves that series' seed out of the house float. A bet too late in the window, below the opening minimum, or against a stale or thin oracle is refused before any market opens.

2. A bet creates a bearer claim

The ticket asks the Markets contract for quote_bet, then the browser creates a random secret and stores poseidon(secret) as the public commitment. The secret is written to the local position record before submission. The pool spends shielded STRK and calls privacy_invoke(OP_BET, …) in the same transaction.

The market uses a constant-product reserve machine. A stake buys tickets; a winning ticket pays one unit of the stake token. Standing series deduct their displayed vig before pricing the tickets. Every rounding decision goes toward the pot so the contract cannot promise more than it holds.

3. The record is public, but has no bettor field

BetPlaced publishes the market id, side, amount, tickets, reserve movement and commitment. The transaction submitter and timing are public too. If a covered transaction is used, the relayer is the submitter and also learns network metadata; otherwise the user's account submits and pays.

The commitment is not an address field. That protects the bettor's identity only when the public facts do not single the position out. A unique amount or an otherwise unique pattern can identify a bet, which is why the app says the denomination needs company.

4. Cash-out, resolve and void are separate doors

Before the deadline, a bettor can sell the whole position back to the machine. The quote moves with the reserves, and the transaction carries a 1% tolerance floor so a worse landing price reverts.

After the deadline, anyone may call resolve during the five-minute resolution window. The contract reads Pragma, checks the price scale and freshness, and for standing markets also checks the minimum source count. Strictly above the line wins Over; equal to or below wins Under.

If no valid resolution lands, anyone may call void after ten minutes. Bettors then reclaim what they paid. A resolved winner claims tickets; a custom-market seeder claims the residual. Each terminal payout is pulled back through the pool into a fresh open note.

Launch architecture

Launch architecture showing public creation, shielded buys through the pool, a bearer commitment and the graduation or refund branches
Launch: creation is a direct account call; buyer value uses the pool; graduation and failure lead to different bearer payouts. Click the image to expand it.

Open the Launch PNG.

1. Creation is deliberately a public path

Creating a launch moves no sale money, so it calls create_launch directly instead of going through privacy_invoke. The transaction's submitting account is public: normally the creator's account, or the relayer when the creator explicitly spends a covered transaction.

Before submission, the browser stores a creator secret and sends only its commitment. That secret controls the later sweep of the raise; the transaction submitter does not. An optional logo is pinned before the chain call when pinning is configured. The contract checks the URI length but does not fetch or endorse whatever the URI serves.

2. The curve advances in whole units

Every epoch contains exactly 16 units. All units inside one epoch have the same price; the unit price is p0 + epoch × step. A purchase that crosses an epoch boundary is split across the curve, so its later units pay the later price. Prices are per unit rather than per token, avoiding a fractional token price that would round to zero in integer contract arithmetic.

The buyer reads quote_buy, chooses a whole-unit count, and reviews the shielded STRK cost. The browser stores a new buyer secret, then the pool sends the stake to privacy_invoke(OP_BUY, …). Bought publishes the launch, starting epoch, units, total cost, post-buy sold count and commitment. It has no buyer-address field, but the amount, timing and transaction submitter remain public.

3. Sold out and missed deadline are different state machines

When every unit sells, anyone may call graduate. The Launch contract deploys a token from its pinned class hash, mints the complete supply to itself and books that supply for buyer redemption. Each buyer reveals the position secret through a pool-only redeem operation, and the launch tokens land as a new pool note.

The creator uses the separate creator secret to sweep the raised STRK to a named public address. That recipient and amount are public. Graduation does not create a DEX market, add liquidity, pay a royalty or offer a buy-back.

If the deadline passes before the units sell out, the first valid refund marks the launch failed. No keeper is required. Each buyer then reclaims exactly that position's recorded cost into a new STRK pool note.

4. Talk is not part of token settlement

Each launch page also exposes an open Talk thread. It uses the same relay family as Chat, keeps at most 50 messages in relay memory and is readable by anyone who derives the room from the launch id. It does not write to the Launch contract and does not affect a buy, graduation, redeem, sweep or refund.

Markets and Launch side by side

BoundaryMarketsLaunch
Free readsMarket registry, events, float, Pragma price and quotesLaunch registry, metadata, curve state and quotes
Opening actionStanding window opens on its first valid bet; custom markets use the poolCreator calls create_launch directly
Buyer inputShielded STRK through the poolShielded STRK through the pool
Public position factsSide, amount, tickets, odds movement, timing and commitmentUnits, cost, epoch, sold count, timing and commitment
Local bearer materialBet or seed secretBuyer secret and, for creators, a separate sweep secret
Early exitWhole-position cash-out before closeNo sell-back before graduation
Success pathPragma resolution, then winning-ticket or seeder-residual claimToken deployment, buyer redemption, public creator sweep
Failure pathPermissionless void, then cash-in refundFirst refund marks failed, then cash-in refund
Returned valueStake-token pool noteLaunch-token pool note on success; stake-token note on failure

Use the Markets guide for the betting flow and the Launch guide for creation, buying and settlement.

On this page