HighLow

HighLow is a Flare-native short-duration binary prediction market. Traders buy HIGHER or LOWER shares with native FLR during a 90-second trading window. The book then locks for 10 seconds. During the following 10-second close window, Flare FTSOv2 determines the result against the stored opening anchor.

LMSR prices entries and early exits. Parimutuel accounting distributes the remaining pool at settlement. Coston2 uses C2FLR with the same 18-decimal base unit model.

Program path, milestones, and go-to-market

HighLow is being prepared for submission to the Flare Summer Signal hackathon. We view the program as the first external product-validation checkpoint in a longer path toward a secure, measurable, and sustainable Flare-native market, not as the endpoint of the project.

HighLow is not being developed as a short-lived hackathon prototype. The repository already contains the Flare-native contracts, immutable FTSOv2 price source, deployment safeguards, cross-implementation quote-model parity tooling, and unit, integration, security, adversarial, and stateful invariant tests. The whitepaper, pitch deck, blurb, and explicit security assumptions document the mechanism, product thesis, commercial case, and current risk decisions.

The project is currently pre-audit and pre-mainnet. Submission to Summer Signal, selection by the program, grant support, investment, or a partnership must not be inferred until it is publicly confirmed.

Summer Signal submission standard

The submission package will be designed for verification, not presentation alone. It will include:

• a concise product demonstration for the intended trader;
• deployed Coston2 contracts and reproducible deployment instructions;
• a precise explanation of how native FLR and FTSOv2 are essential to the product rather than incidental integrations;
• a dated distinction between the protocol baseline and new work completed for the program; and
• public technical materials, known limitations, and measurable next steps.

Milestone plan

Milestone	Delivery objective	Exit evidence
1. Summer Signal submission	Present a reproducible Coston2 product build, verified contract addresses, a working round demonstration, clear Flare integration, and a transparent record of work completed for the program.	Public submission materials, deployment details, demo evidence, and a documented next-step plan.
2. Coston2 validation	Operate the complete oracle and market lifecycle continuously under realistic conditions. Instrument live-close coverage, manual-fallback rate, FTSOv2 feed age, transaction cost, round participation, and two-sided depth.	A 14-day soak test covering the resulting round cadence, with no unresolved accounting or liveness failure and a published reliability report.
3. Security and mainnet readiness	Commission an independent smart-contract audit, address or explicitly accept every finding, harden operational key management, add oracle automation redundancy and monitoring, and complete incident-response and launch runbooks.	Public audit artifacts, reviewed fixes, a production launch checklist, and legal and compliance clearance for the intended launch markets and jurisdictions.
4. Controlled Flare launch	Launch a focused BTC/USD 100-second market with native FLR, conservative parameters, monitored operations, and a limited initial user cohort.	Stable settlement performance, measurable repeat use, healthy two-sided participation, and evidence that acquisition can convert into retained traders.
5. Market-network expansion	Add more suitable FTSOv2 feeds and market clocks, then evaluate N-outcome markets, reusable market templates, and FDC-resolved event markets.	Each expansion ships behind its own specification, threat model, tests, audit scope, and product-demand evidence.

Go-to-market discipline

The initial wedge is deliberately narrow: crypto-native Flare users who want a fast, legible BTC/USD view without order-book management or a token-approval workflow. Native FLR settlement, a continuous quote, an optional early exit, and a result every 100 seconds create a compact activation and retention loop: observe, choose, trade, resolve, repeat.

Distribution will begin through the Summer Signal submission, Flare developer and community channels, transparent Coston2 demonstrations, technical content, and integrations with relevant ecosystem wallets and applications. Growth will be evaluated through funded traders, first-trade conversion, participating rounds per user, D1 and D7 retention, two-sided round coverage, volume, early exit activity, protocol fees, timely-finalization rate, and VOID rate. Broader feeds, incentives, or market formats will follow measured retention rather than replace it.

Funding strategy

The intended sequence is evidence first, capital second. After the hackathon, the team plans to pursue milestone-based support from the Flare ecosystem for security review, Coston2 operations, production monitoring, and user-product delivery. Strategic angels and network-aligned venture investors may then be approached to accelerate engineering, compliance, ecosystem distribution, and measured mainnet growth once reliability and retention are demonstrated.

Because real round liquidity is funded by traders and virtual liquidity is math-only, external capital is not required to underwrite directional market risk. Grant or venture funding would finance product quality, security, operations, and distribution instead of subsidizing a protocol balance sheet.

Milestone, ecosystem, and investment discussions: info@a16.com.

Protocol properties

• Native FLR or C2FLR is the only value path.
• Each round freezes its LMSR liquidity parameter b at initialization.
• A 10-second lockout closes trading before the live close window begins.
• The opening anchor and closing result both come from one immutable FtsoV2PriceSource.
• An explicit oracle closes and advances rounds. The owner can rotate it.
• Timely closes read FTSOv2 directly. After 10 seconds, the oracle must provide a nonzero manual closing price before progression can resume.
• Every next-round opening price always comes from live FTSOv2.
• VOID refunds are proportional to remaining cost basis.
• Early sells pay a 0.50% fee on gross proceeds.

Each deployment follows one FTSOv2 reference series. The default deployment profile uses BTC/USD, but the feed id is a deployment parameter and is fixed inside the immutable source.

Market model

For outstanding HIGHER shares H, LOWER shares L, and frozen liquidity b:

C(H, L) = b * ln(exp(H / b) + exp(L / b))

buy cost      = C(after) - C(before)
sell proceeds = C(before) - C(after)

Final settlement is parimutuel:

directional payout = pool * userWinningShares / totalWinningShares
VOID payout        = pool * userRemainingCost / totalRemainingCost

Virtual liquidity is math-only. It is not deposited capital. The real pool starts at zero and contains trader funds net of completed sell proceeds.

Round lifecycle

An on-time round follows a 120-second cadence. A delayed close or next-price transaction shifts later rounds instead of skipping ids or shortening a round:

round start          +90s             +100s       +110s       +120s
    |------------------|----------------|------------|-----------|
       buy and sell          locked       FTSOv2       next-price
                                          close        registration
                                                           next round

Constant	Value	Meaning
TRADE_DURATION	90 seconds	Buy and sell window
TRADE_LOCKOUT	10 seconds	Frozen book before outcome sampling
ROUND_DURATION	100 seconds	Round open to beginning of close window
FTSO_CLOSE_WINDOW	10 seconds	Live FTSOv2 close window after round end
NEXT_ROUND_DELAY	20 seconds	Earliest on-time next-round start after round end
ON_TIME_ROUND_PERIOD	120 seconds	Round cadence when both oracle calls are timely

FTSOv2 close and next-round anchor

The oracle first calls finalizeFromFtso(id) during the 10 seconds immediately after roundEnd. HighLow reads the current immutable FTSOv2 source and records the price, result, and FTSOV2 provenance. Closing does not initialize the next round.

If no successful live close lands before roundEnd + 10 seconds, the market hard-stops. Only the configured oracle can restore it by calling finalizeWithManualPrice(id, closePrice). This trusted fallback records MANUAL provenance. It cannot be used during the live FTSOv2 window.

Once the close exists and the second 10-second interval has begun, the oracle calls startNextRound(id). The opening price is always read from current FTSOv2, never typed or carried from the previous round. A call before roundEnd + 20 seconds creates a pending round that opens at that timestamp. A later call starts it immediately with a complete 100-second lifecycle.

When the anchor is registered during seconds 110 to 120, it is deliberately frozen until the scheduled opening. It can therefore be up to 10 seconds old at open. The scheduled horizon from anchor publication to the next close-window start is 100 to 110 seconds. The actual FTSOv2 publication used to close may land anywhere in the following 10-second window. Calling startNextRound after the scheduled opening starts immediately and restores a 100-second scheduled horizon.

Coston2 testnet profile

Parameter	Initial value	Role
DEFAULT_VIRTUAL_LIQUIDITY	10 C2FLR	Testnet LMSR depth
minBuyWAD	0.01 C2FLR	Minimum testnet buy
maxBuyWAD	1 C2FLR	Maximum testnet buy per call
minSideStakeWAD	0.1 C2FLR	Absolute testnet side materiality floor
minSidePoolBP	500	5% proportional materiality floor
maxPriceDeviationBP	500	5% opening-to-closing bound
vlMin	1 C2FLR	Automatic-depth lower bound
vlMax	500 C2FLR	Automatic-depth upper bound
MAX_VIRTUAL_LIQUIDITY	10,000,000 native units	Shared hard depth ceiling
autoVL	false	Automatic depth disabled initially
SELL_FEE_BP	50	0.50% gross early-sell fee

The initial public profile is intentionally scaled for faucet-funded Coston2 testing without changing the model's relative risk geometry: minimum buy is b / 1,000, maximum buy is b / 10, the absolute side floor is b / 100, and the automatic-depth range is b / 10 to 50b. These owner-tunable native values are a testnet accessibility profile, not a USD peg or a recommended Flare mainnet launch profile.

The materiality rules require both sides to hold shares and clear both money floors:

costH >= minSideStakeWAD
costL >= minSideStakeWAD
min(costH, costL) / (costH + costL) >= minSidePoolBP / 10,000

Interface

The implementation inherits IHighLow.sol. Primary methods are:

startRound()
finalizeFromFtso(uint256 id)
finalizeWithManualPrice(uint256 id, uint64 manualClosePrice)
startNextRound(uint256 previousId)

buy(uint256 id, bool isHigher, uint256 amount, uint256 minShares) payable
sell(uint256 id, bool isHigher, uint256 shares, uint256 minOut)
claim(uint256 id)

quoteBuy(uint256 id, bool isHigher, uint256 amount)
quoteSellGross(uint256 id, bool isHigher, uint256 shares)
quoteSellNet(uint256 id, bool isHigher, uint256 shares)

All lifecycle functions are oracle-only. startRound and startNextRound read FTSOv2 themselves. Only the post-deadline manual close accepts caller-supplied price data.

Repository layout

contract/       market, canonical interfaces, FTSOv2 source, and feed library
script/         atomic Flare deployment and quote-model parity tooling
test/unit/      core market behavior and economic profile
test/feeds/     FTSOv2 source and feed conversion tests
test/integration/ lifecycle, FTSOv2 settlement, timing, and deployment
test/security/  regressions, adversarial scenarios, and accepted risks
test/invariant/ stateful accounting and liveness properties
docs/           published whitepaper, pitch deck, and investor blurb

Build and test

FOUNDRY_OFFLINE=true forge build --offline
FOUNDRY_OFFLINE=true forge test --offline

FOUNDRY_OFFLINE=true forge script --offline script/GenerateQuoteVectors.s.sol:GenerateQuoteVectors
node script/check_quote_calculator.mjs

Flare deployment

The guarded script supports only Flare mainnet (chain ID 14) and Coston2 (chain ID 114). Mainnet additionally requires ALLOW_MAINNET=true.

Deployment is atomic: the script resolves FastUpdater and FastUpdatesConfiguration from Flare's canonical registry, deploys the ownerless immutable FTSOv2 source, and then deploys HighLow bound to that source and an explicit oracle signer. There is no source wiring transaction.

cp .env.example .env
set -a
source .env
set +a

cast chain-id --rpc-url "$COSTON2_RPC_URL"

forge script script/DeployHighLow.s.sol:DeployHighLow \
  --rpc-url "$COSTON2_RPC_URL"

Simulate first. Add --broadcast --slow --verify only after reviewing the trace and every resolved environment value. Full instructions are in script/README.md.

Official references:

• Flare developer documentation
• FTSOv2 overview
• FTSOv2 feed table
• Coston2 faucet

Security

The FTSOv2 source is immutable and cannot be replaced by the owner. Owner authority remains over economic parameters, pause state, automatic depth, fee withdrawal, and oracle rotation. The oracle has trusted manual-close authority after a missed live window. claim and lifecycle functions remain available while trading is paused. Accepted risks and reassessment triggers are recorded in SECURITY.md.

Project: a16k-lab, info@a16.com.