how SaySo actually works.

what is sayso, in one sentence?

A Solana prediction market with a native lending stack that lets users borrow stablecoins against open positions and lever into conviction bets — without ever leaving capital trapped until resolution.

what's actually novel here?

Three things, in order of how much they matter:

1. Position-as-collateral. Your YES or NO position is a real productive asset, not a locked bet. You can borrow against it without closing it.
2. Loop-in (one-click leverage). A relay-driven session-key model executes the full borrow → buy → redeposit → borrow loop atomically with one signature, and you keep custody throughout.
3. LLTV time decay. A protocol-enforced invariant that no leveraged position survives to resolution. Eliminates the binary-resolution bad-debt vector that has been the unsolved problem for every leveraged prediction-market design to date.

why does this matter?

Polymarket, Kalshi, and the clones all leave capital trapped until resolution. That's a feature for the house and a tax on the user. The capital-efficiency layer is what turns a prediction market from a static bet into a live position you can actually trade around — which is the difference between something a degen uses once and something a serious user lives in.

what's the market structure?

Native YES/NO outcome markets with off-chain matching and on-chain settlement. Real orderbook, not a bonding curve. Prices live in [$0, $1] and reflect the implied probability of YES.

where do prices come from?

Other traders. SaySo runs the matching engine; the orderbook is the truth. Resolution pays $1 per share to the winning side and $0 to the losing side.

can i exit before resolution?

Yes. Sell into the book at any time the market is open. If you have debt against the position, the close proceeds repay the debt first; the remainder is yours.

what categories of markets are in scope?

Culture, sports, crypto, politics, finance, geopolitics, earnings, tech. The product is deliberately built for headline-driven, fast-moving markets and is positioned as the fun, culturally-fluent alternative to the serious, institutional-leaning forecasting brands in the category. Different audience, different tone, different velocity.

how does borrowing work?

Take a position. Draw stablecoins against it up to a market-specific LLTV cap. The position stays open. The borrowed stablecoins are unconditionally withdrawable to the user's wallet or redeployable inside the protocol. No close, no exit, no opportunity cost.

what backs the borrow?

The mark price of your outcome tokens, on the live SaySo orderbook. Health factor is computed as:

HF = collateral × price × effective_LLTV / debt

Where effective_LLTV is normally the market's nominal LLTV but decays toward zero in the resolution window — see the Time decay section.

what happens if my health drops?

The liquidation keeper closes the position at a discount. The Liquidator Vault funds the close, takes the seized collateral, and either sells it on the orderbook or holds it to resolution. You get back whatever's left after debt + liquidation incentive fee.

where do the borrowed stablecoins come from?

The GlobalSupplyVault — a community-funded pool of stablecoins, supplied by LPs in exchange for borrower interest.

what is loop-in?

The product design is that the user signs once to authorize a LeverageAuthorization PDA — a session key with a TTL, scoped to a specific market and a specific kind of action — and a relay-side execution worker then drives the leverage loop on their behalf:

borrow → buy outcome tokens on SaySo → redeposit as collateral → borrow → ...

Each iteration is a separate transaction (the matching engine is off-chain queued, so "atomic" isn't the right word for the loop), but the user only goes through a single signing event for the whole sequence, and custody never leaves them.

In this demo build, the on-chain PDA scaffolding is in place but the relay-side executor isn't yet running — so loop-in currently runs as a client-side iterative loop, with the user signing each iteration. Functionally identical end state; the UX gap closes when the relay-side worker ships.

why a session-key model instead of a solver?

Two reasons. First, it eliminates the trust gap of a solver holding inventory on the user's behalf — the relay only ever spends the user's own pre-approved SPL delegate allowance. Second, it routes through SaySo's own native orderbook instead of an external CLOB, which removes a major correlated dependency and a known failure mode in similar products on other chains.

can the user revoke the authorization?

Yes, at any time. The PDA is closeable by the user. TTLs are bounded and the front-end blocks any authorization that extends past the relevant market's decay window.

what's the worst case for a leveraged user?

Total loss of collateral. Leverage means amplified losses, including 100% of the position. Time decay protects the protocol from bad debt; it does not protect the user from being on the wrong side. This is the right place for that risk to land.

how do markets resolve?

Optimistic resolution. After the underlying event, anyone can propose the outcome on-chain by posting a bond. The proposal then enters a fixed dispute window. If unchallenged at expiry, the market finalizes and pays out. If a disputer posts a counter-bond inside the window, resolution escalates to a second-stage adjudication before the canonical answer is committed.

The whole stack lives in the on-chain resolution state plus seven on-chain instructions covering propose, dispute, escalate, finalize, redeem, and edge-case handling.

why optimistic resolution instead of an oracle?

Most market outcomes are not contested. An optimistic mechanism gets those through cleanly and fast at near-zero cost. The dispute path exists exactly for the cases that need it — ambiguous wording, contested events, judgment calls — and the bond mechanic makes frivolous disputes economically irrational.

A pure oracle model collapses on ambiguous markets (it just picks something) and a pure committee model is slow and centralized. Optimistic resolution is the equilibrium that's been stress-tested at scale by UMA and Polymarket and continues to be the right call for this category.

what's the dispute window?

Configurable per-market and surfaced on the market page. Short, fact-of-record markets (a single match score, a Pyth tick at a specific timestamp) carry shorter windows; ambiguous or judgment-heavy markets carry longer ones. The protocol enforces the window cryptographically — no admin can shortcut it.

what happens during the dispute window?

Trading is closed; the market is in resolution state. Borrowers can still repay and withdraw — anything that reduces protocol risk stays open. Anything that adds risk (new positions, new borrows) is blocked.

who decides if a dispute is escalated?

The dispute mechanism itself. A disputer with a bond at stake forces the second-stage adjudication. If the second stage rules in their favor, they win the proposer's bond; if it rules against them, they lose theirs. The economics make the system self-policing.

what problem does it solve?

A leveraged prediction-market position has a unique failure mode that ordinary lending protocols don't face: the collateral can go to zero in a single block when the market resolves against the collateral side. A position at 70% LTV against YES at $0.51 is healthy by every conventional measure right up to the moment NO wins — at which point YES is $0, the debt is unchanged, and the lender eats the entire shortfall. There is no price drift. The price gap is the resolution event itself.

Without a mechanism to address this, every leveraged position on the losing side becomes underwater simultaneously, in one block, and the keeper cannot serve them all. This has been the structural ceiling on every leveraged prediction-market product to date.

how does decay solve it?

The protocol linearly reduces the effective LLTV from its nominal value toward zero over a fixed window before the resolution timestamp:

effective_LLTV(t) =
  if t ≤ t_start:   LLTV_nominal
  elif t ≥ t_zero:  0
  else:             LLTV_nominal × (t_zero − t) / (t_zero − t_start)

Where t_start and t_zero bracket a window of several days ending shortly before resolution. Inside the window, every leveraged position becomes liquidatable at some point — even with no price movement — and the keeper unwinds them in an orderly cadence over days rather than all in one block.

what's the design invariant?

No leveraged position survives to resolution. This is enforced by the protocol, not assumed by convention. By the time the market reaches its resolution timestamp, every leveraged position has been either deleveraged voluntarily by the user or unwound by the keeper.

Unlevered positions are completely unaffected and run straight through to resolution at full payout.

what does the user experience?

The position panel surfaces:

• when decay starts for each market the user holds
• the current effective LLTV and how it compares to their borrow LTV
• an estimated time-to-forced-unwind based on current decay schedule
• explicit copy distinguishing "you got liquidated because price moved" from "you got unwound because the market is approaching resolution"

The leverage slider is bounded by current effective LLTV, not nominal, so users can't accidentally take new leverage they're already inside the decay window for.

what's allowed inside the decay window?

Asymmetric gating. Repay, withdraw-to-deleverage, voluntary close, and liquidation are all open. New borrows, new leverage jobs, and any action that increases protocol risk are blocked. The asymmetry is intentional and load-bearing — the entire safety property of decay relies on it.

why linear decay specifically?

Linear gives a predictable, communicable schedule and avoids the cliff problem (binary cutoffs cause cascade liquidation in a single block, which is the thing decay is supposed to prevent). It's the simplest function that satisfies the safety invariant and remains easy to compute on-chain in integer arithmetic with rounding rules that always favor the protocol.

the supply vault

GlobalSupplyVault. LPs deposit stablecoins; borrowers draw against their open positions. LPs earn the borrower interest spread. Utilization-based interest curve, kinked, with the standard upward slope past the optimal utilization target.

Yield source: borrower interest. Real revenue from real product usage — no token emissions, no subsidy.

Risk: credit risk. A bad-debt event (i.e. a liquidation that doesn't cover the debt) hits the Supply Vault first. Time decay is the primary defense; conservative LLTV caps are the secondary defense.

the liquidator vault

LiquidatorVault. A community-funded pool that fronts the stablecoins to execute liquidations, takes seized outcome-token collateral, and either sells it on the orderbook or holds it to resolution and redeems for the full $1-per-share if that side wins.

Yield source: the liquidation incentive fee (LIF) — a discount captured every time the vault closes an unhealthy position. Plus principal recovery on held positions that win.

Risk: inventory risk. The vault can end up holding outcome tokens that ultimately resolve to $0. The math relies on a steady stream of liquidations across markets — one bad market doesn't sink the vault, but a one-sided concentration would.

why are these two vaults separate?

Different risk profiles, different yield profiles, different LP audiences. Mixing them would force one risk model on capital that wants two. Keeping them separate also lets the protocol adjust each independently — for example, adding per-asset debt caps to the Supply Vault without touching the Liquidator Vault economics.

where does the yield ultimately come from?

Borrowers using leverage (Supply Vault) and liquidations executing under decay (Liquidator Vault). Both are product revenue paid by active participants — no token emissions, no subsidy. When something big is happening in the world, the vaults are working harder; in quiet weeks, they're not. That's the right alignment, and it's the part that makes this a genuinely uncorrelated yield stream for the broader stablecoin ecosystem.

who is this product actually for?

Pure traders are welcome — running a vault is a clean way for an alpha-confident bettor to monetize their edge without managing anyone else's capital directly. But that's not the headline target.

The headline target is the global tipster market. In tradfi sports betting, paid tipster subscriptions are roughly a $500M/year business — and the betting volume those subscriptions drive is estimated at at least 20× that, north of $10B/year. Punters pay monthly fees to follow someone else's picks via Telegram channels, Discord servers, paywalled newsletters, and tipster apps. The whole category runs on trust ("did this person actually go 12-3 last month?"), opaque settlement, and zero accountability when the picks underperform.

Web3 has not touched this market. SaySo's Vaults give it the right primitive natively: every pick is on-chain, every PnL is verifiable, every leader's track record is auditable from genesis, and the follower's capital is locked into the strategy execution — there's no way for a leader to claim wins they didn't take. The trust problem the tipster industry is built on dissolves.

what does a tipster-led vault actually look like?

A tipster shares their thesis publicly (Twitter, YouTube, podcast, whatever), points followers at their on-chain vault, and lets the vault execute their picks. Followers deposit, performance accrues, profits split per the configured fee. No "bet $50 and follow my Telegram" — the bet is the follow.

yield source and risk

Yield source: the leader's strategy itself. No protocol-side promise, no subsidy — followers get whatever the leader's bets get, minus the agreed fee.

Risk: leader risk. Followers are trusting a specific person's judgment. The vault enforces transparency (positions, PnL, history all public) and fee caps, but strategy quality is entirely on the leader. The protocol's contribution is making leader quality legible — which is exactly the thing the tradfi tipster market can't do.

why solana?

Three reasons:

1. Latency. Headline-driven markets need sub-second order matching, on-chain confirmation in seconds, and fees under a cent. Solana's the only L1 that gets there at the price point.
2. Account model. The PDA model maps cleanly onto session keys, which is what makes the loop-in UX work without a custodial relay.
3. Whitespace. No flagship consumer prediction-market brand has shipped on Solana yet. Polymarket is on Polygon, Kalshi is centralized, the clones are aggregators or thin frontends. The category is open.

why a native lending stack instead of plugging into an existing one?

For outcome-token collateral (YES/NO tokens), no general-purpose lending protocol can price the asset correctly or handle the resolution edge case. Outcome tokens are bounded in [0, 1], settle to a binary outcome, and require LLTV decay machinery that doesn't exist anywhere else. So the bet-token-as-collateral path has to be native — there's no alternative.

For crypto-token collateral (SOL, etc.), the calculus is different and the design plugs into Kamino via CPI. Kamino owns the credit primitive, SaySo owns the UX layer. That's a separate path from the native bet-token stack and runs in parallel.

why optimistic resolution rather than uma / reality.eth / a centralized arbitrator?

We're not running our own dispute committee from day one. UMA and Reality.eth aren't on Solana. The native optimistic mechanism gives us the right shape — propose, dispute, finalize, with bonded participants — and a clean upgrade path to swap in an external adjudicator for the second stage if the dispute frequency justifies it later.

why a session-key relay instead of a solver?

Solver models require the solver to hold inventory and route through external orderbooks. That creates a trust gap (the solver's behavior must be verifiable post-hoc) and a correlated dependency (if the external book is down, leverage is down). Session keys via LeverageAuthorization PDA route through SaySo's own native orderbook, with the user's own pre-delegated SPL allowance, and require no inventory. Cleaner trust model and one fewer external failure mode.

what's the biggest open risk?

Liquidator Vault inventory imbalance during a high-correlation event. If a major market resolves in a way that liquidates a lot of leveraged positions on the same side at once, the vault ends up holding a concentrated bag. Time decay spreads the unwinds out over days to soften this, but doesn't fully eliminate the correlation. Per-market debt caps and a more aggressive partial-sell-on-liquidation flow are the next mitigations.

what's working end-to-end?

• Native YES/NO market with off-chain matching and on-chain settlement
• Outcome-token-as-collateral lending: deposit + borrow live; repay and withdraw exist on chain but lack a front-end surface in this build
• Leverage via client-side iterative loop-in through the borrow primitive (user signs each iteration; the relay-side LeverageAuthorization-driven executor is the next build)
• LLTV decay math, asymmetric gating, and front-end decay-state surfacing — all on chain (per-market decay configs are deployed on selected demo markets)
• Optimistic resolution on chain — propose, dispute, finalize, redeem instructions all working; operator-driven via CLI scripts in this build, no end-user UI yet
• Supply Vault deposit and withdraw functional; Liquidator Vault deposit functional, withdraw and the keeper-driven liquidation flow scaffolded but not running
• Vaults (Hyperliquid-style copy-trading) — vault creation and depositor flow live; leader-signed trade-intent submission to the matching engine wired at the wire-protocol level but lacks a leader-facing UI

what's stubbed or scoped down for the demo?

• A single featured market on the front page rather than a full market list
• Resolution UI exists but is operator-driven via CLI for some flows
• The crypto-collateral path (SOL → borrow USDC → bet) is architected but not in this demo build
• Per-user borrow caps not yet wired in
• Loop-in signing UX. The session-key model is implemented, but in this demo build the user still signs each loop iteration. In production, the LeverageAuthorization PDA is honored end-to-end and the relay executes the full loop with zero further user signatures. The remaining build is the relay-side execution worker that consumes a LeverageAuthorization PDA to drive borrows on the user's behalf — the on-chain auth scaffolding and the front-end signing flow are both already wired.

what's strategically out of scope but on the roadmap?

• Fully gasless / delegated-signing UX. True one-tap leverage with no per-step signatures and no SOL in the user's wallet for fees. Optional and opt-in, but the default path for the mainstream-friendly UX layer.
• Simplified UI for non-crypto-native users. A slimmed-down surface that hides the lending vocabulary entirely — fiat in, bet, payout, fiat out — for users who want the product without ever seeing the words "LLTV" or "liquidation."
• Squads multisig migration for protocol authority
• Kamino-CPI crypto collateral path
• Dashboard / analytics for the LP-facing vault products
• Mobile-first UX layer

who is this for, in what order?

SaySo's DeFi layer (capital efficiency, lending, leverage) is the wedge — it's how we get a head start on the crypto-native audience already on Solana, where there's no flagship consumer prediction-market brand. That's the first user base.

The longer game is the global betting market. The simplified UI, the gasless UX, the fiat rails — those exist because the eventual addressable market isn't crypto-native users. It's everyone who currently uses Paddy Power, Betfair, DraftKings or FanDuel and would prefer something faster, cheaper, more transparent, and capital-efficient. The DeFi layer makes the product genuinely better; the consumer layer makes that "better" reachable by people who don't know what a wallet is.

• Settlement chain: Solana — sub-second matching, on-chain confirmation in seconds, fees under a cent
• Market structure: native YES/NO orderbook, off-chain match / on-chain settle
• Resolution model: optimistic, bonded propose / dispute / finalize
• Lending stack: native, with LLTV decay before resolution
• Lending vaults: Supply Vault (borrower interest), Liquidator Vault (LIF + held collateral) — uncorrelated, event-driven yield
• Vaults: Hyperliquid-style copy-trading, targeting the global tipster market
• Safety invariant: no leveraged position survives to resolution