How to Develop a No-Vig Betting Platform With Real-Time Odds?

Key Takeaways

• A no-vig betting platform removes the bookmaker margin from the price, so both sides of a market sum to 100 percent implied probability instead of the 104 to 110 percent a traditional sportsbook prices in.
• Removing the vig is arithmetic, not magic: convert odds to decimal, derive implied probability, sum the overround, and normalize back to 100 percent.
• The genuinely hard engineering problem is not the de-vig math, it is real-time odds: a single NFL game can generate more than 50,000 price updates, and production pipelines target sub-100ms delivery at the 99th percentile.
• Revenue moves from the margin to commission, subscriptions, market-maker fees, or spread capture, with live exchange commissions currently ranging from 0 percent to 6 percent.
• A production no-vig platform with real-time odds typically costs $120,000 to $450,000 and takes 5 to 14 months, depending on licensing path and matching engine complexity.

Every sportsbook in the world makes money the same way: it prices a margin into the odds and collects it whether the bettor wins or loses. A no-vig platform deletes that margin and replaces it with a different revenue model entirely, which changes the product, the economics, and the engineering all at once. The category is no longer theoretical either. Novig, which built its business on a no-vig pitch, received a Commodity Futures Trading Commission designated contract market approval for its Ludlow Exchange in June 2026, launched nationwide on August 4, 2026, and has raised more than $105 million at a reported $500 million valuation against $6 billion in cumulative trading volume.

This guide covers the full build: the de-vig math, the real-time odds pipeline that is the actual hard part, the architecture, the data providers, the regulatory paths, and what it costs to ship with Idea Usher.

What Is a No-Vig Betting Platform?

A no-vig platform prices markets at their true implied probability rather than at a marked-up price that guarantees the house a margin. To see why that matters, it helps to look at what the vig actually is.

How the Vig Works in a Traditional Sportsbook

Take a standard two-way market priced at -110 on both sides. The bettor risks $110 to win $100 on either outcome. Converted to implied probability, each side reads 52.38 percent, and the two sides together sum to 104.76 percent.

Probability cannot exceed 100 percent. That extra 4.76 percent is the overround, and it is the sportsbook’s margin. Expressed as a share of the total market, it works out to roughly 4.55 percent of every dollar wagered. Practically, it means a bettor has to win about 52.4 percent of their bets just to break even, before showing any profit at all.

What Changes in a No-Vig Model

A no-vig platform prices that same market at 50 percent and 50 percent, summing to exactly 100 percent. The break-even win rate drops to a flat 50 percent, and the structural cost of participating disappears.

That is only possible if the operator is not the counterparty. A sportsbook takes the other side of every bet, so it carries risk and needs the margin to stay solvent. A no-vig platform matches users against each other, or lists contracts that settle against a verified outcome, and never holds a position. The absence of the margin is a consequence of that architecture, not a promotional discount, a point covered in more depth in Idea Usher’s breakdown of how a platform like Novig makes money.

How to Calculate No-Vig Odds

The de-vig calculation is the foundation of the pricing engine, and it is worth implementing correctly because every downstream number depends on it.

The Standard Method, Step by Step

1. Convert American odds to decimal. For positive odds, decimal = (odds / 100) + 1. For negative odds, decimal = (100 / absolute value of odds) + 1.
2. Derive implied probability for each outcome as 1 / decimal odds.
3. Sum the implied probabilities across every outcome in the market.
4. Calculate the overround by subtracting 1 from that sum.
5. Calculate the vig percentage as (overround / sum of probabilities) multiplied by 100.
6. Normalize each outcome by dividing its implied probability by the sum, which rescales the market back to exactly 100 percent.

Worked through on a -110 / -110 market:

• Decimal odds: (100 / 110) + 1 = 1.909 on each side
• Implied probability: 1 / 1.909 = 0.5238, so 52.38 percent per side
• Sum: 1.0476, an overround of 4.76 percent
• Vig: 0.0476 / 1.0476 = 4.55 percent
• No-vig probability: 0.5238 / 1.0476 = 0.5000, or exactly 50 percent

The de-vig math on a standard -110/-110 market: each side implies 52.38% probability, the market sums to 104.76%, the vig is 4.55%, and the true no-vig probability is 50%

Which De-Vig Method Should You Use?

The method above is the multiplicative or proportional approach, and it is the industry default because it is fast, stable, and easy to audit. It does carry a known bias: it distributes the margin evenly in proportional terms, which tends to understate the true probability of heavy favorites and overstate longshots.

Teams building serious pricing engines usually implement more than one method and compare:

• Multiplicative (proportional): divide each implied probability by the sum. Fast, the default, slightly biased on lopsided markets.
• Additive: subtract an equal share of the overround from each outcome. Simple, but can produce negative probabilities on extreme longshots.
• Power: solve for an exponent that makes probabilities sum to 1. Handles favorite and longshot bias better, costs more compute.
• Shin: models the margin as protection against insider betting. Best theoretical fit on many markets, hardest to implement and tune.

For a two-way market the methods barely diverge. On three-way markets and heavily lopsided lines the gap becomes material, which is why the de-vig method belongs in configuration rather than hardcoded into the pricing service.

How Does a No-Vig Platform Make Money?

This is the question every investor asks, and it has a clear answer: the revenue moves off the price and onto the transaction or the account.

The strategic read matters as much as the numbers. A sportsbook earns more when users lose, which is why winning accounts often get limited. A commission or subscription platform earns more when users stay and keep trading, so it has no reason to restrict winners. That difference is a marketing asset, and it is also a compliance asset as regulators pay closer attention to how operators treat profitable customers.

Common revenue models in production:

• Commission on winnings, the exchange standard, typically 1 to 5 percent
• Taker-only fees, charging the aggressor and rewarding liquidity providers
• Market-maker agreements, where institutional liquidity pays for access
• Spread capture, where the platform quotes a narrow two-sided price
• Subscription tiers, trading transaction fees for recurring revenue
• Premium data access, selling the no-vig feed itself to sharp bettors and modelers

Why Real-Time Odds Are the Hard Part

Teams routinely underestimate this. The de-vig math is a few dozen lines of code. The real-time odds infrastructure behind it is a distributed systems problem that runs continuously under bursty, unforgiving load.

The scale is the first surprise. A single NFL game can generate more than 50,000 price updates across its lifetime, and major sporting events drive volume spikes of roughly 20x over baseline. Every one of those updates has to be ingested, normalized, de-vigged, matched against resting orders, and pushed to every connected client before it is stale.

What Latency Target Should You Actually Hit?

Published production pipelines give two useful reference points. A well-engineered ingestion path reports end-to-end latency of 18ms at p50, 47ms at p95, 81ms at p99, and 142ms at p99.9. A more conservative sportsbook backend design targets a full odds-update cycle of roughly 425ms typical with a p99 ceiling under 2 seconds, broken down across stages.

Latency budget across the real-time odds pipeline, from provider ingest through de-vig recalculation to the WebSocket push that reaches the client

The number that actually matters is not the average, it is the tail. A platform that is fast at p50 and slow at p99 will fail precisely when volume spikes, which is exactly when money is moving. Stale odds on a no-vig platform are worse than on a sportsbook too, because there is no margin absorbing the error.

How to Choose a Real-Time Odds Data Provider

Almost no team should build odds collection from scratch at launch. The decision that matters is whether the provider pushes data or makes you poll for it.

Three practical selection criteria:

• Sharp book coverage matters more than book count. A de-vig engine benchmarked against Pinnacle produces a far more defensible fair price than one averaging forty recreational books that are all copying each other.
• Push beats polling at scale. Polling once per second across live events costs roughly 86,400 requests per day per stream and still adds up to a second of staleness. WebSocket delivery removes that floor.
• Billing models differ wildly. Some providers bill per credit where one call costs markets multiplied by regions, others bill per object or per request. Model your actual query pattern against the pricing page before committing, because the headline monthly price is frequently not what you will pay.

Idea Usher’s guide to integrating an AI sports betting API like Sportradar or Betradar covers the integration layer in more depth, and the same feed architecture underpins betting arbitrage platforms like OddsJam, which depend on exactly this kind of multi-book normalization.

Reference Architecture for a No-Vig Platform With Real-Time Odds

A production system separates into five independently scalable layers. Keeping them decoupled is what allows one stage to spike without taking down the rest.

The real-time odds pipeline for a no-vig platform: ingest provider feeds, buffer through a message queue, normalize and de-vig, match against the order book, then push to clients and settle

Layer 1: Ingestion

Maintain persistent WebSocket connections to each provider with explicit ping keepalives on a roughly 20-second interval, and stamp every inbound event with a high-precision timestamp on arrival. Those timestamps are what make latency debugging possible later. Write raw events straight into a message queue without transforming them: Kafka with partitioning suited to your event volume, compression enabled, and a retention window of about seven days so the stream can be replayed when the normalization logic changes.

Layer 2: Normalization and the De-Vig Engine

This is where provider-specific payloads become a single internal schema and where the de-vig calculation runs. Two implementation details separate a system that works from one that survives:

• Deduplicate with a sliding window. A Redis-backed 60-second window keeps duplicate provider events from being processed twice.
• Micro-batch the writes. Collecting events into 250ms batches before flushing has been reported to cut write latency by around 60 percent, because it converts thousands of tiny writes into a manageable number of larger ones.

Layer 3: Order Book and Matching Engine

On a peer-to-peer no-vig platform this is the core asset. The engine has to match opposing positions with price-time priority, support partial fills when order sizes do not line up, hold both stakes in escrow, and update the visible price the instant the book changes, all without the operator taking a position on either side. That last constraint is what keeps the model structurally distinct from a sportsbook, and it has to be enforced in the architecture rather than in policy. Idea Usher’s teardown of building a P2P betting marketplace like BettorEdge covers this component in detail.

Layer 4: Distribution

Clients receive updates over WebSocket rather than polling. Two patterns matter at scale: send deltas instead of full market snapshots, and version every odds payload so the bet acceptance layer can reject a stake placed against a price that has already moved.

Layer 5: Settlement

Markets move through explicit states, pending to confirmed to settled, and resolve against a verified data source. Every settlement writes to an immutable ledger. On any platform holding user funds this is audit surface, not just business logic.

Failover and Graceful Degradation

Live odds feeds fail, and the platform has to degrade rather than break. A three-layer approach is standard:

1. Primary provider feed, typically around 99.98 percent uptime, which still means roughly 105 minutes of downtime a year.
2. Warm cache fallback, serving last-known state from Redis with a short TTL and an explicit staleness flag attached to the payload so the UI can warn the user.
3. Circuit breaker, tripping after a few consecutive provider errors and retrying after a cooldown of roughly 30 seconds instead of hammering a failing endpoint.

The rule that keeps operators out of trouble: when data is stale, suspend the market rather than accept bets against a price you cannot verify.

Sportsbook vs No-Vig Platform: What Actually Changes

A traditional sportsbook takes the other side of every bet and prices a margin into the odds, while a no-vig platform matches users at true probability and earns through commission instead

Core Features Checklist

• Real-time odds ingestion from one or more providers with failover
• De-vig pricing engine with configurable methodology
• Order book and matching engine with price-time priority and partial fills
• Escrow and settlement logic that never puts the operator on one side
• WebSocket distribution with delta updates and odds versioning
• Bet acceptance layer that validates against the current odds version
• Market state machine covering pending, suspended, confirmed, and settled
• KYC, geo-fencing, and responsible gambling controls
• Wallet supporting fast deposits and withdrawals
• Admin dashboard for market oversight, suspension, and dispute resolution
• Market surveillance tooling to flag manipulation and collusion
• Immutable audit ledger for every price, match, and settlement

Tech Stack for a No-Vig Betting Platform

• Frontend: React or Next.js for web, React Native or Flutter for mobile
• Backend: Go, Rust, or Node.js for the matching engine, Python for pricing and modeling
• Streaming: Kafka for the raw event backbone, with partitioning matched to peak volume
• Hot state: Redis for the live order book, dedup windows, and warm-cache fallback
• Time-series storage: TimescaleDB or similar for historical odds, with compression on older chunks
• Transactional store: PostgreSQL for accounts, wallets, and the settlement ledger
• Real-time transport: WebSocket, with autoscaling connection gateways
• Observability: latency histograms at every stage, not just averages, plus staleness alerting
• Compliance: KYC provider, geo-fencing service, and market surveillance tooling

Which Regulatory Path Should You Take?

This decision shapes the entire build and should be settled before significant engineering budget is spent. There are three viable routes in the United States right now.

• State-by-state gaming licensure. The traditional path. Slow and expensive, requiring separate approval in nearly every state, with ongoing compliance overhead in each. Sporttrade operates on this model as a licensed exchange.
• Federal CFTC designated contract market. The route Novig took, receiving DCM approval for its Ludlow Exchange in June 2026 and reaching all 50 states at 21-plus from launch on August 4, 2026. A single federal filing replaces the state patchwork, but DCM registration is a long, heavily scrutinized process.
• Partnering with an existing licensed exchange or DCM. Most new entrants start here, because it converts a multi-year regulatory timeline into a commercial negotiation.

The architecture implications are real. A DCM-oriented build needs regulatory-grade market surveillance, trade reporting, and audit infrastructure from day one, which is a materially heavier engineering lift than a state-licensed exchange. Idea Usher’s prediction marketplace development work covers both paths.

How to Build a No-Vig Betting Platform: Step by Step

Six steps to build a no-vig betting platform with real-time odds: map the regulatory path, integrate odds feeds, build the de-vig pricing engine, build the matching engine, wire real-time distribution, then test and launch

The order below is not arbitrary. Each phase produces something the next phase depends on, and the two most common ways these projects fail are starting the engineering before the licensing path is settled, and building the matching engine before the price feed it matches against is reliable.

Phase 1: Regulatory Mapping and Market Definition (Weeks 1 to 5)

Nothing else gets scoped correctly until this is done, because the licensing route determines the surveillance, reporting, and audit requirements that every later component has to satisfy.

What actually happens: counsel selects between state licensure, CFTC DCM registration, and partnering with an existing licensed exchange. In parallel the team defines which sports and market types launch first, which states or jurisdictions are in scope, and what the age gate is per jurisdiction. The de-vig methodology gets chosen per market type, and the fee model gets locked, because a commission model and a subscription model imply different wallet and ledger designs.

Deliverables: licensing decision with a filing or partnership plan, jurisdiction and age-gate matrix, market scope document, fee model specification, and a compliance requirements list that feeds directly into the data model.

Where teams go wrong: treating this as a legal workstream that runs alongside engineering rather than ahead of it. A DCM-oriented build needs trade reporting and immutable audit trails designed into the schema from the first migration. Retrofitting that later means rewriting the settlement layer.

Phase 2: Odds Feed Integration and Normalization (Weeks 4 to 11)

What actually happens: the team selects a primary provider and at least one fallback, prioritizing sharp book coverage and WebSocket delivery over raw bookmaker count. Persistent connections get built with ping keepalives on a roughly 20-second interval. Every inbound event is stamped with a high-precision arrival timestamp and written raw into the message queue before any transformation, with about a seven-day retention window so the stream can be replayed when normalization logic changes.

Then the harder half: mapping every provider’s event identifiers, market types, and team naming to a single internal schema. This is unglamorous and consistently underestimated. A deduplication window of roughly 60 seconds stops duplicate provider events being processed twice, and micro-batching writes into 250ms windows has been reported to cut write latency by around 60 percent.

Deliverables: live ingestion service with failover, raw event stream with replay capability, normalization layer with a canonical schema, dedup and batching in place, and latency instrumentation at every stage.

Where teams go wrong: transforming events at ingest. Once the raw stream is lossy, every normalization bug becomes permanent because there is nothing to replay.

Phase 3: De-Vig Pricing Engine (Weeks 9 to 14)

What actually happens: the calculation itself is quick to implement. The engineering work is making it configurable, testable, and observable. The methodology (multiplicative, additive, power, or Shin) belongs in configuration per market type, not hardcoded. The engine needs a regression test suite covering two-way markets, three-way markets, heavy favorites, and extreme longshots, because that is exactly where methods diverge and where an additive implementation can produce a negative probability.

Every computed price carries a version number and the inputs it was derived from. Without that lineage, disputes become unresolvable and the bet acceptance layer in Phase 5 has nothing to validate against.

Deliverables: pricing service with configurable methodology, regression suite across market shapes, price versioning and lineage, and a fair-price benchmark comparing output against sharp book consensus.

Where teams go wrong: hardcoding multiplicative de-vig and discovering months later that three-way markets are mispriced against every competitor.

Phase 4: Order Book, Matching Engine, and Escrow (Weeks 12 to 22)

This is the longest and most expensive phase, and on a peer-to-peer platform it is the core asset.

What actually happens: the engine matches opposing positions with price-time priority, supports partial fills when order sizes do not line up, holds both stakes in escrow, and updates the visible book the instant it changes. The single hard constraint is that the operator never takes a position, and that has to be enforced structurally rather than by policy, because it is what keeps the model legally distinct from a sportsbook.

Escrow and the settlement ledger are built alongside it. Every state transition, pending to suspended to confirmed to settled, writes an immutable record. On any platform holding user funds this is audit surface first and business logic second.

Deliverables: matching engine with price-time priority and partial fills, escrow service, immutable settlement ledger, market state machine, and a reconciliation job proving book state matches ledger state.

Where teams go wrong: building a matching engine that works at demo volume and has never been tested against concurrent order flow on a single market. Race conditions in matching are financial bugs, not display bugs.

Phase 5: Real-Time Distribution and Client Apps (Weeks 18 to 26)

What actually happens: clients move to WebSocket rather than polling. Two patterns decide whether this scales: send deltas rather than full market snapshots, and version every odds payload so the bet acceptance layer can reject a stake placed against a price that has already moved. Connection gateways need to autoscale, since concurrency spikes long before an event starts, not during it.

Graceful degradation gets built here too. A three-layer approach is standard: primary provider feed, warm cache fallback serving last-known state with a short TTL and an explicit staleness flag the UI can display, then a circuit breaker that trips after a few consecutive provider errors and retries after roughly 30 seconds. The governing rule is that when data is stale, the platform suspends the market rather than accepting bets against a price it cannot verify.

Deliverables: WebSocket gateway with autoscaling, delta update protocol, odds versioning enforced on the acceptance path, failover and circuit breaker logic, and web and mobile clients.

Where teams go wrong: shipping full snapshots on every tick, which works fine with 200 concurrent users and collapses at 20,000.

Phase 6: Load Testing, Compliance Sign-Off, and Launch (Weeks 24 to 32)

What actually happens: the platform gets load-tested against a realistic peak, not an average Tuesday. That means modeling the roughly 20x spike a marquee event produces and the 50,000-plus price updates a single NFL game generates, then measuring p95 and p99 rather than averages. A security audit covers the wallet, escrow, and withdrawal paths. Compliance sign-off confirms surveillance, reporting, and responsible gambling controls are live.

The last step is commercial, not technical: seed the liquidity. A no-vig exchange with an empty order book offers a worse experience than a sportsbook with a margin, so market-making arrangements or seeded liquidity need to be in place before the first user arrives.

Deliverables: load test report at projected peak, security audit sign-off, compliance certification, market surveillance live, liquidity plan executed, and a monitored launch.

Where teams go wrong: treating liquidity as a growth problem to solve after launch. It is a launch requirement.

Phase Timeline and Team at a Glance

Phases overlap in practice, which is why a production build lands at roughly 5 to 9 months rather than the sum of every phase. Phase 3 typically starts while Phase 2 is still stabilizing, and client work in Phase 5 begins against mocked data well before the matching engine is finished.

Development Cost and Timeline

Feature-level costs break down further, since each component is scoped and built separately:

Recurring costs sit outside these ranges and are easy to forget at budgeting time: odds data subscriptions run from roughly $99 to $499 per month at the entry tiers and materially higher for sharp-inclusive enterprise feeds, plus streaming and database infrastructure, KYC per-verification fees, and legal review. Idea Usher’s breakdown of sports betting app development costs covers how these variables move on a conventional build for comparison.

Common Mistakes to Avoid

• Optimizing the average and ignoring the tail. A p50 of 20ms means nothing if p99 is two seconds. The tail is what breaks during a marquee event, which is exactly when volume and money peak.
• Hardcoding a single de-vig method. Multiplicative de-vig is a reasonable default and a poor universal answer. Make it configurable per market type.
• Launching without liquidity. A no-vig exchange with no resting orders offers a worse experience than a sportsbook with a margin. Plan market-making or seeded liquidity before launch, not after.
• Accepting bets against stale prices. Without odds versioning on the acceptance path, every feed hiccup becomes a priced-in loss the operator cannot recover.
• Treating compliance as a later phase. Surveillance and audit requirements shape the data model. Retrofitting them means rewriting the settlement layer.
• Underestimating the 20x spike. Infrastructure sized for an average Tuesday will fall over on the first championship Sunday.

Why Partner With Idea Usher to Build Your No-Vig Platform

A no-vig platform with real-time odds is two hard systems fused together: a low-latency data pipeline and a financial matching engine. Idea Usher has spent over a decade building exactly this category of software.

Over 10 Years Building Money-Moving Software

Idea Usher has operated for more than 10 years with a team of 250-plus specialists across AI, blockchain, and fintech development, with direct experience building order books, wallets, and settlement systems rather than standard consumer apps.

Real-Time Trading and Exchange Architecture

Idea Usher’s prediction marketplace development and peer-to-peer sports betting app development practices are built around central limit order books, real-time infrastructure sized for peak-event load, and settlement systems that resolve against verified data sources.

Compliance Mapped Before the Build Begins

Builds run through a staged process: requirements and licensing-path selection, architecture and UX design, trading infrastructure development, data integration, testing, and deployment, with legal and regulatory mapping happening before the majority of the engineering budget is spent.

A Track Record Backed by Real Numbers

Idea Usher has delivered more than 1,000 projects across 50-plus countries, holds a 95 percent client retention rate, and carries Clutch recognition as a top app development and top blockchain company for 2026.

Idea Usher by the numbers: 10+ years in business, 250+ niche experts, 1,000+ projects delivered, 50+ countries reached, 95% client retention, Top 2026 Clutch App and Blockchain Company

If you are scoping a no-vig betting platform or a real-time odds product, talk to Idea Usher’s team about your prediction marketplace development options, or book time directly with Nitish Garg to walk through your pricing engine, latency targets, and licensing path.

Conclusion

Building a no-vig betting platform is less about removing a number from a price and more about rebuilding the business around the absence of that number. The de-vig arithmetic takes an afternoon. The real work is a real-time odds pipeline that survives 50,000 price updates per game and 20x event spikes, a matching engine that never puts the operator on one side of a trade, and a revenue model that earns from commission or subscription instead of margin. Novig’s path from startup to CFTC-approved exchange in all 50 states shows the category is viable at scale. For founders entering it now, the differentiator will not be the no-vig claim, which is becoming table stakes, but whether the odds are genuinely live when it matters most.

FAQs

What does no-vig mean in betting?

No-vig means the odds carry no built-in bookmaker commission, so all outcomes in a market sum to exactly 100 percent implied probability instead of the 104 to 110 percent typical of a traditional sportsbook line.

How do you calculate no-vig odds?

Convert each side’s odds to decimal, take 1 divided by the decimal for implied probability, sum those probabilities across the market, then divide each individual probability by that sum to normalize back to 100 percent. On a -110 / -110 market this turns 52.38 percent per side into exactly 50 percent.

How does a no-vig betting platform make money?

Through commission on winnings (typically 1 to 5 percent), taker-only fees, institutional market-maker agreements, spread capture, subscription tiers, or selling premium data access, rather than through a margin priced into the odds.

What latency should a real-time odds platform target?

Well-engineered pipelines report roughly 18ms at p50 and under 100ms at p99 for ingestion, while a full odds-update cycle including recalculation and client push typically targets around 425ms with a p99 ceiling under 2 seconds.

Which odds API is best for a no-vig platform?

The one that carries sharp books and supports WebSocket delivery. Coverage of Pinnacle-style sharp lines matters more than raw bookmaker count, because a fair price benchmarked against sharp markets is far more defensible than an average of recreational books.

How much does it cost to develop a no-vig betting platform?

Typically $60,000 to $450,000 depending on scope, with a market-ready production platform including real-time odds, a matching engine, and compliance achievable for $120,000 to $280,000 in 5 to 9 months.

Do I need a license to launch a no-vig betting platform in the US?

Yes, via one of three routes: state-by-state gaming licensure, federal CFTC designated contract market registration (the path Novig took for its Ludlow Exchange in June 2026), or partnering with an already licensed exchange, which is where most new entrants start.

What is the hardest part of building a no-vig platform?

The real-time odds infrastructure, not the de-vig math. A single NFL game can produce more than 50,000 price updates, major events drive roughly 20x volume spikes, and stale prices are unrecoverable on a platform with no margin to absorb the error.

Is a no-vig platform the same as a betting exchange?

They overlap heavily. Most no-vig platforms are exchanges, since matching users against each other is what makes removing the margin structurally possible, though some operate as CFTC-regulated event contract markets rather than as gaming exchanges.