Prediction Market Arbitrage: How to Hedge Between Polymarket and Mirror Markets

If you already run a Polymarket bot, the next opportunity may not be another prediction model. It may be a second liquidity surface where your existing pricing, execution and risk stack can work harder.

Prediction-market arbitrage sounds simple on a spreadsheet.

Find the same event at two venues.

Buy the cheaper side.

Sell the more expensive side.

Keep the difference.

In production, the hard part is not finding two similar headlines. It is proving that both instruments have the same payoff, mapping their outcome tokens correctly, executing both legs at real prices, and surviving the time between entry and settlement.

That is especially important when the second venue is a mirror market. A Polymarket mirror can give a market maker a useful external reference and a potential hedge for Kuest flow. But a mirror is not permission to assume that every price difference is risk-free arbitrage.

This guide is for crypto-native market makers, quantitative traders and desks that already understand cross-venue execution. It explains how to think about a prediction market arbitrage strategy between Polymarket and Kuest mirror markets, where shared liquidity changes the opportunity, and how Kuest’s funded campaigns and on-chain escrow can turn ad hoc quoting into a repeatable mandate.

What Is Prediction Market Arbitrage?

Prediction market arbitrage is the attempt to capture a pricing difference between economically equivalent contracts, or to construct a position whose combined payoff is known while the entry cost is below that payoff.

There are two ideas that are often grouped together under the word arbitrage.

Complementary-outcome arbitrage

In a binary market, YES and NO are complementary outcomes. If a trader can buy YES on one venue and NO on another for a combined executable cost below $1, and both contracts resolve under exactly the same rules, the gross settlement value is $1.

The simple edge is:

gross edge = $1 - (YES entry price + NO entry price)

The real edge is smaller after taker fees, gas, slippage, failed or partial fills, capital lock-up and any cost of getting the two positions to settlement.

Cross-venue inventory hedging

A market maker may not be trying to lock in a guaranteed payout at all. It may be quoting on one venue and using another venue to reduce the inventory created by customer flow.

For example, if a Kuest customer buys YES from your ask, your quoting engine may buy the corresponding YES exposure on Polymarket, sell an existing position there, or use an equivalent complementary position depending on your inventory and execution model.

The objective is to reduce net delta, not necessarily to lock a fixed spread at the instant of every fill.

The distinction matters for your bot, your capital model and your risk disclosures. A locked complementary pair can have a calculable settlement value. A hedge of market-maker inventory can still lose money when the hedge is late, the markets diverge, or the external book disappears.

The PredictEngine guide to prediction-market arbitrage uses the same practical framing: the price gap has to be evaluated after fees and slippage, and mid-prices are not executable prices. The Preduck cross-venue documentation is also useful for understanding how listed markets are matched and how cross-venue prices should be compared rather than treated as interchangeable tickers.

Why Polymarket Traders Look for Mirror-Market Arbitrage

Polymarket is a natural reference venue for prediction-market market makers because it has deep market data, an active CLOB, established order-flow patterns and a large population of traders and bots.

But a reference venue and a complete business opportunity are not the same thing.

Crypto-native traders look for additional surfaces for several reasons:

• A branded operator can bring a different audience and different flow.
• A market may be in demand on an operator site before it has meaningful local depth.
• A market maker can earn a negotiated liquidity payment in addition to trading P&L.
• Separate operator frontends can create flow around the same underlying event.
• A desk can reuse parts of its Polygon, CLOB, quoting and inventory infrastructure.
• The maker may find temporary differences in fees, urgency, latency or order-flow composition.

This is the core Kuest proposition for an experienced MM: the operator network creates more demand for professional liquidity, while Polymarket mirrors can provide a useful price reference or external hedge when the contract specifications actually align.

Kuest is not presenting every operator frontend as an isolated exchange. Its architecture connects branded deployments to shared market discovery, order matching, wallet operations and lifecycle data. Compatible outcome token IDs use common Kuest order books, so orders from one Kuest-powered site can match compatible orders already resting from another.

That has an important consequence:

A difference between two Kuest operator pages is not automatically an arbitrage opportunity.

If the pages expose the same shared book, the apparent difference may be a presentation, cache or timing issue. The more interesting cross-venue relationship is usually between Kuest network flow and an external reference such as Polymarket, or between an operator market and a separate market with a carefully validated payoff.

How Kuest Mirror Markets Work

The word “mirror” describes the relationship between a Kuest market and a selected external market source. It does not mean that the frontend simply embeds another venue’s order book.

An operator can choose to expose a catalog that combines selected Polymarket mirrors, operator-created markets and other explicitly shared sources. The operator owns the branded experience and audience. Kuest provides the trading infrastructure that connects that experience to market data, order matching, relayed wallet actions and Polygon settlement.

For a market maker, the useful mental model is:

1. The source market provides the reference specification. Read the question, outcomes, close time, resolution source and edge cases.
2. Kuest creates a compatible market representation. The mirror has its own Kuest-side market metadata and order-book context.
3. The outcome mapping must be explicit. A bot needs to know which Kuest token corresponds to the source YES and NO tokens.
4. Kuest flow is attributed to the originating operator. Trades from the site, a bot or an SDK can be connected to that operator’s economics.
5. Settlement and resolution need their own checks. A price relationship is only as strong as the market lifecycle behind it.

The Kuest architecture documentation explains the model in more detail: operators control their brand, domain, site experience and operations, while Kuest provides shared CLOB and market services. The open-source Kuest repository documents the Polygon, USDC, API and SDK foundation for operators and builders.

Mirror markets versus operator-created markets

The distinction is important when you model hedgeability.

If the market is proprietary, the campaign payment has to compensate for the additional pricing and inventory risk. If the market is a mirror, the external reference can reduce some uncertainty, but only after contract-level validation.

The Polymarket Hedge Strategy: Trade the Same Outcome Across Venues

A useful Polymarket hedge strategy starts with the position your Kuest book actually has, not with a generic assumption that YES on one page equals YES everywhere.

Hedge a filled quote with the same outcome

Suppose your Kuest market maker quotes YES at $0.54 and a customer buys 1,000 YES contracts. You have sold 1,000 YES from your inventory.

If your strategy wants to keep the same event exposure near zero, it can buy 1,000 equivalent YES contracts on Polymarket, if the external book offers sufficient executable ask depth. That replenishes the economic YES inventory you sold, while the difference between the Kuest sale and Polymarket purchase contributes to the trade-level economics.

This is an inventory hedge, not automatically a risk-free arbitrage. The hedge may fill at $0.56, partially fill, or not fill at all. The Kuest and Polymarket contracts may resolve differently. Your net result also includes fees, gas, quote maintenance and the chance that the Kuest flow was informed.

Construct a complete pair with opposite outcomes

Suppose you can buy YES on Kuest at $0.53 and buy NO on Polymarket at $0.43. If the two contracts have identical resolution rules, the combined entry cost is $0.96 for a position that pays $1 at settlement.

gross locked-pair edge = $1.00 - $0.96 = $0.04 per pair

This is the cleaner arbitrage structure, but it is only as clean as the match between the contracts and the fills. If you can execute 1,000 complete pairs, the gross amount is $40 before all costs. A bot must reject the opportunity if only 700 YES contracts and 400 NO contracts are executable: the guaranteed quantity is 400, and the remainder is an unhedged position.

Hedge using the relationship between YES and NO

On binary markets, the outcome pair has a natural relationship. Kuest’s CLOB and Polygon exchange support the underlying transfer, split and merge mechanics needed to settle complementary positions. Kuest’s architecture documentation describes buying YES and NO as a way to mint a complete pair from $1 collateral, and selling both as a way to merge a complete pair back to $1 when the economics permit it.

That does not mean a frontend should hide what happened. A bot and its operator dashboard should preserve the trader’s physical action — BUY YES, SELL NO, and so on — while its accounting layer understands the complementary settlement mechanics.

A Step-by-Step Prediction Market Arbitrage Example

Consider a market maker that has accepted a Kuest campaign for a Polymarket mirror.

The desk’s objective is to quote the Kuest market, use the Polymarket market as a reference and keep inventory within a defined risk band.

Step 1: Validate the contract

The bot loads the Kuest market, the Polymarket source market and the resolution metadata. It verifies that the question, outcome order, close time, resolution source and edge-case rules match the desk’s hedge policy.

If the mapping is uncertain, the bot marks the market as non-hedgeable rather than guessing.

Step 2: Read executable books

The bot reads the best bid, best ask and available size on both venues. Polymarket’s official order book endpoint returns price/size levels plus fields such as timestamp, minimum order size and tick size. Its market-by-token endpoint helps map a token back to its parent condition and primary or secondary outcome.

The midpoint is useful for monitoring. It is not enough for execution.

Step 3: Choose the hedge route

Assume the desk has sold 1,000 Kuest YES contracts at $0.54. The Polymarket YES ask is $0.55 for 600 contracts and $0.57 for 700 more.

The first 600 can be replenished at $0.55. The next 400 would be more expensive, and the desk may decide to:

• hedge only 600 and keep 400 contracts inside its risk band,
• cross the next price level if the campaign payment and expected flow justify it,
• use a complementary NO route if the contract and settlement model support it,
• or widen/cancel Kuest quotes until inventory returns to target.

The correct choice comes from the risk engine, not from the headline spread.

Step 4: Calculate the net result

For a same-outcome inventory hedge, one simplified trade-level calculation is:

net trading result = Kuest sale proceeds
                   - Polymarket hedge cost
                   - Kuest fees
                   - Polymarket fees
                   - gas and transaction costs
                   - expected slippage
                   - inventory and capital cost

For a complete complementary pair, use the settlement value only if the contracts are truly equivalent:

net locked-pair edge = guaranteed settlement value
                     - YES cost
                     - NO cost
                     - all venue fees
                     - gas
                     - slippage
                     - operational and capital costs

Step 5: Reconcile every state

The bot confirms whether each order was accepted, partially filled, canceled, rejected or still resting. It updates both venue inventories and records the exact token IDs, prices, fees and timestamps.

A trade that is “probably filled” is not a hedge. A position that is missing from the reconciliation ledger is not neutral just because the strategy expected it to exist.

Step 6: Monitor through settlement

If the hedge is a locked pair, the desk still monitors resolution and redemption. If it is an inventory hedge, the desk monitors both books, market status and any change in the relationship between the source and mirror.

The market maker should have explicit rules for widening, reducing size, canceling quotes, escalating a contract mismatch and stopping a market when the hedge venue becomes unavailable.

How to Find Mirror Markets and Map Outcome Tokens

The most dangerous implementation shortcut is matching by title alone.

The Assymetrix cross-venue arbitrage analysis explains why: trader populations, liquidity, fees, capital requirements and resolution rules can make two similar-looking markets behave differently. It also highlights the practical problem of near-identical headlines that resolve under different criteria.

Store a contract-level market map

For every mirror, keep a durable mapping object similar to:

{
  "source": "polymarket",
  "sourceConditionId": "0x...",
  "sourceYesTokenId": "...",
  "sourceNoTokenId": "...",
  "kuestConditionId": "0x...",
  "kuestYesTokenId": "...",
  "kuestNoTokenId": "...",
  "resolutionSource": "...",
  "closeTime": "...",
  "mappingStatus": "verified"
}

The exact schema is yours to implement, but the properties are not optional. A human-readable title is for discovery. A condition ID and outcome-token mapping are for execution.

Kuest market details expose the mirror relationship and CLOB context needed for this workflow, including mirror condition IDs, mirror token IDs, outcomes, fees, resolution source and best bid/ask information. Your bot should treat that data as an input to validation, not as a substitute for its own persisted mapping and reconciliation.

Reject ambiguous mappings

Your market scanner should return “no trade” when:

• YES and NO are reversed between venues;
• the source market has a different close timestamp;
• the resolution source is missing or different;
• one market can be canceled under a rule the other does not have;
• the token mapping changed after market creation;
• the market is paused, resolved or in a disputed state;
• or the available size is below your minimum complete hedge.

The opportunities you skip are cheaper than the positions you cannot explain at settlement.

Shared Liquidity Changes the Arbitrage Equation

Shared liquidity is one of the most important differences between a network of Kuest operator sites and a collection of independent venues.

When compatible markets use the same Kuest outcome token IDs, they use the same Kuest order books. An order resting from one operator frontend can be available to a trader arriving through another. The operator controls the presentation and attribution; the matching engine is not spun up as an isolated book for every brand.

For market makers, shared liquidity can improve capital efficiency:

• one quote can serve demand from multiple operator audiences;
• a new frontend can launch with more than its own day-one order flow;
• liquidity is less likely to be trapped behind one brand’s URL;
• operators can fund targeted campaigns when network depth is not enough;
• and market makers can evaluate demand at the network level rather than only by individual page.

But shared liquidity can also change the way you interpret a price gap.

The same Kuest book is not two independent arbitrage legs

If two sites show different cached snapshots, the apparent difference may vanish when you fetch the live book. If two orders match inside the same Kuest CLOB, the desk is not capturing a venue-to-venue spread; it is participating in the common market.

The relevant edge may come from:

• the relationship between Kuest flow and Polymarket execution;
• an operator’s funded liquidity requirement;
• fee or incentive economics;
• inventory imbalance across the network;
• or a temporary difference between an external reference and the shared Kuest book.

That is why the Kuest protocol model and market-maker page should be read together. One explains the network and operator economics. The other exposes the funded liquidity mandates that can pay a professional desk for maintaining depth.

Market Maker Inventory: Collateral, YES/NO Tokens, and Settlement

A binary market maker usually manages at least four related balances:

1. Collateral, typically USDC, available for orders and settlement.
2. YES inventory, which can be sold to customers or used to complete a pair.
3. NO inventory, with the complementary payoff.
4. External-venue inventory, which may be used to replenish or offset Kuest fills.

The correct hedge depends on the exact balance sheet, not only on the last trade.

Why complete pairs matter

If a desk owns one YES and one NO for the same binary condition, the pair has a $1 combined settlement value under the market’s rules. Depending on the venue mechanics, the pair can be split from collateral or merged back into collateral.

For a market maker, this creates a useful accounting primitive. A quote can be filled in YES while the risk engine tracks whether the desk owns the complementary NO, can acquire it cheaply, or can hedge the YES exposure elsewhere.

It does not remove resolution risk. The two tokens still need a common condition, common outcome definitions and a valid settlement path.

Keep physical actions and accounting actions separate

One operational pitfall is labeling a customer-visible SELL YES as a merge operation because the backend may use complementary settlement mechanics.

Keep the user and audit trail honest:

• the order log records the submitted side and token;
• the risk engine records the resulting inventory;
• the settlement layer records split/merge or transfer operations;
• and the reconciliation process links the states together.

This separation makes debugging and dispute analysis much easier, especially when a mirror market has a problem.

How Much Edge Is Left After Fees, Gas, and Slippage?

The most common arbitrage error is subtracting fees from a midpoint spread while ignoring the rest of the execution path.

Use the price and size you can actually execute. Polymarket publishes a spread endpoint, but a narrow top-of-book spread does not tell you whether enough size exists for your trade. The CLOB market information endpoint exposes market parameters such as tokens, tick size, fees, minimum order size and rewards that also belong in the model.

A practical net-edge formula

net edge = gross payoff or spread capture
         - entry fees on every leg
         - exit or settlement fees
         - gas and relayer costs
         - expected slippage
         - failed-fill and retry cost
         - capital lock-up cost
         - hedge execution cost
         - operational overhead

For a $0.04 gross locked-pair edge, 1.5¢ of combined fees, slippage and gas leaves 2.5¢ before capital and operational cost. If one leg fills only 70% of the intended size, the remaining 30% is a directional position, not part of the locked pair.

Include the campaign payment separately

Kuest campaign compensation is payment for a defined liquidity service. It should appear as a separate revenue line in the model rather than being silently mixed into the arbitrage edge.

That makes your decision clearer:

expected campaign P&L = trading P&L
                     + campaign reward
                     + eligible incentives
                     - bond opportunity cost
                     - infrastructure cost
                     - adverse selection
                     - hedge and inventory losses

The reward may make a mandate attractive even when it is not a pure arbitrage. Conversely, a large reward does not make an impossible spread requirement or a broken hedge acceptable.

The Main Risks in Polymarket Mirror Arbitrage

Basis risk

The contracts can differ in a single clause that changes the payoff. Compare data sources, timestamps, geographic scope, market close, resolution authority and cancellation conditions.

Execution and latency risk

The cheap leg can disappear before the hedge order reaches the book. A bot needs time-to-live controls, atomicity assumptions that are explicit, and a policy for unhedged partial fills.

Liquidity and size risk

The displayed best ask may be available for 20 contracts while your hedge needs 2,000. Depth is part of price.

Adverse selection

The trader lifting your quote may be responding to new information. A market maker can lose on the hedge even when the book looked balanced a moment before.

Resolution and settlement risk

The market may resolve later than expected, enter a dispute, or use a rule your contract map did not capture. Capital can remain locked while the desk waits for a final outcome.

Venue and operational risk

API outages, rate limits, rejected orders, stale websockets, wallet errors, relayer issues and reconciliation bugs can create exposure that a pricing model never saw.

Regulatory and counterparty risk

Prediction markets, derivatives, market making and access rules can be regulated differently across jurisdictions. A professional desk must obtain its own legal, compliance and tax advice before operating, and it should evaluate the rules for every market and user segment it serves.

The Assymetrix article on cross-venue prediction-market scanners makes the same practical point from an execution perspective: capital, KYC, funding, withdrawal and resolution exposure remain part of the strategy even when a scanner identifies a visible price difference.

How Kuest Market Maker Campaigns Pay for Liquidity

Pure arbitrage is opportunistic. A liquidity campaign is a commercial mandate.

An operator or sponsor can fund a campaign with terms such as:

• market or series scope;
• service start and end dates;
• required liquidity per side;
• maximum allowed spread;
• coverage or availability percentage;
• campaign reward;
• optional bond;
• whether an external Polymarket hedge is available;
• and review, dispute and settlement conditions.

The Kuest market-making article explains why these opportunities exist: operators need executable depth, especially for new mirrors and proprietary markets, while professional market makers need compensation for capital, infrastructure and risk.

The escrow flow

Kuest’s MarketMakerEscrow coordinates the commercial obligation on Polygon:

1. The sponsor funds the campaign with the reward and required protocol amounts.
2. An approved market maker reviews the terms and accepts with its payout account.
3. If required, the market maker deposits the campaign bond.
4. The maker provides the agreed liquidity during the service period.
5. The campaign enters review, where material violations can be reported under the terms.
6. Once finalized, the maker’s allocation becomes withdrawable through pendingWithdrawals.

Acceptance locks the mandate under its signed terms. Escrow coordinates payment and dispute handling; it does not guarantee that the market maker’s hedge fills or that its strategy earns a positive trading return.

For implementation details, read the Kuest market-maker page, the market creation API and the resolution API. Those systems matter because a market maker cannot model a hedge correctly without understanding how markets are created, paused, resolved and attributed.

Prediction Market Arbitrage Bots and API Infrastructure

A serious bot should treat cross-venue arbitrage as a state machine, not as a loop that compares two numbers.

The minimum components

Your stack needs:

• source and mirror market discovery;
• contract and token mapping;
• live order-book ingestion;
• fair-value and executable-edge calculations;
• order sizing by available depth;
• fill and cancellation reconciliation;
• inventory and collateral accounting;
• hedge routing;
• settlement and resolution monitoring;
• alerting, kill switches and audit logs.

Polymarket’s official market-data overview separates Gamma metadata, CLOB prices/order books and Data API positions/trades. Its order submission API also makes the order fields explicit: token ID, side, amounts, owner/auth and order type. Use those primitives in your integration rather than assuming that a displayed web price is an executable order.

A robust execution sequence

discover -> validate mapping -> read depth -> calculate net edge
         -> reserve collateral -> place first leg
         -> confirm fill -> place hedge -> reconcile both venues
         -> monitor settlement -> release or rebalance inventory

The first and second legs do not always need to be submitted in the same order. That is a strategy decision based on which venue is more liquid, which leg is more urgent, whether partial fills are acceptable and how much capital the desk can keep unhedged.

Reuse a Polymarket bot carefully

An existing Polymarket bot can provide a useful starting point for Kuest, especially if it already supports Polygon wallets, CLOB books, cancel-and-replace, inventory bands, websocket recovery and structured logs.

But do not copy the venue adapter and assume the work is done. Validate:

• Kuest market and token identifiers;
• mirror metadata and source mapping;
• authentication and wallet flow;
• order and cancellation semantics;
• fee attribution;
• rate limits and error states;
• shared-book behavior across operator frontends;
• market pause and resolution states;
• and campaign obligations such as spread, depth and coverage.

The Kuest model is designed to be bot-friendly, with APIs, SDKs and shared liquidity infrastructure. The integration still belongs in your risk and reconciliation framework.

How to Start Market Making on Kuest

If your desk already has a prediction-market strategy, the practical path is to start with a narrow mandate.

1. Review the Kuest market-maker page and the protocol model.
2. Connect the wallet that will operate and receive campaign allocations.
3. Apply for approval through the contact path shown on the market-maker page.
4. Once approved, inspect open campaigns and filter for Polymarket hedge availability, event scope, spread, depth and duration.
5. Validate the mirror mapping and external book independently before accepting.
6. Accept only a campaign that fits your inventory and operational limits. Approve the bond token if the mandate requires one.
7. Start with conservative size, verify the full order/fill/reconciliation path, then scale within the signed terms.
8. Finalize and withdraw the campaign allocation after the service and review periods complete.

The first campaign should be treated as an integration and operations exercise as well as a P&L opportunity. A desk that can prove reliable quoting, clean inventory accounting and disciplined hedge behavior becomes more valuable to future operators.

Why Native Crypto Market Makers Are Valuable to Kuest

Kuest does not need a market maker who simply deposits capital and waits for organic volume.

It needs desks that understand:

• how to quote a binary CLOB;
• how to price information risk;
• how to manage YES/NO inventory;
• how to hedge without confusing correlation for equivalence;
• how to handle partial fills and stale books;
• how to operate Polygon wallets and USDC collateral;
• how to keep a bot online through API and market-state changes;
• and how to report and reconcile performance.

That expertise lets an operator launch a market with a credible trading experience instead of hoping that an order book appears after distribution begins.

It also creates a more interesting MM opportunity than a single isolated market. A Kuest operator can bring its own community and fees. The network can provide shared compatible liquidity. A sponsor can fund a specific gap. A market maker can bring pricing and execution across the surfaces where its strategy has an edge.

The Kuest shared-liquidity article describes the network effect from the operator side. For a market maker, the practical translation is simple: every new operator can create another source of qualified flow, while a common infrastructure layer reduces the cost of connecting to it.

Further Reading

• How Polymarket order books work
• How to submit a Polymarket order
• Kuest architecture: operators, shared liquidity and settlement
• Kuest market-maker campaigns and escrow
• Cross-venue prediction-market arbitrage scanner research
• Prediction-market arbitrage guide
• Cross-venue hedging and market matching

FAQ: Prediction Market Arbitrage

What is prediction market arbitrage?

Prediction market arbitrage is the attempt to capture a pricing difference between equivalent event contracts or construct complementary positions whose combined settlement value exceeds their total executable cost. The strategy is only as strong as its contract match, fills, fees and settlement assumptions.

Is Polymarket arbitrage risk-free?

No. A visible price difference can disappear before execution, and two similar markets can resolve differently. Even a complete YES/NO pair can carry execution, capital, venue and settlement risk if the contracts or fills are not truly equivalent.

What is a Polymarket mirror market?

A Polymarket mirror is a Kuest market related to a selected Polymarket source market so an operator can expose that event through its own branded experience. The relationship can provide a reference or potential hedge, but the market maker must verify the outcome mapping, resolution rules and available liquidity.

How does a Polymarket hedge strategy work?

A market maker uses Polymarket to reduce exposure created by quoting on another venue. It may buy the same outcome to replenish inventory, trade the complementary outcome, or construct a complete pair. The correct route depends on contract equivalence, depth, fees, partial-fill risk and the desk’s inventory policy.

Can shared Kuest liquidity remove arbitrage opportunities?

It can remove some differences between Kuest operator frontends because compatible markets use shared order books. That is a feature for capital efficiency, not a problem. Market makers should look for real external price, flow, fee or campaign differences rather than treating two views of the same book as independent venues.

Which IDs should an arbitrage bot map?

At minimum, map the source condition ID, source YES and NO token IDs, Kuest condition ID, Kuest YES and NO token IDs, resolution source, close time and mapping status. Persist the mapping and reject trades when any critical field is missing or ambiguous.

How do I calculate prediction market arbitrage edge?

Start with executable price and size, then subtract every fee, gas, expected slippage, failed-fill cost, capital cost, hedge cost and operational expense. For a complementary pair, use $1 as the settlement value only when the two contracts have identical payoff and resolution rules.

Can I use an existing Polymarket bot on Kuest?

Possibly. Existing Polygon wallet, CLOB, pricing, inventory and reconciliation infrastructure may transfer, but the Kuest adapter must be validated for mirror identifiers, shared-book behavior, authentication, fees, order semantics, market lifecycle and campaign obligations.

What is Kuest MarketMakerEscrow?

MarketMakerEscrow is the Polygon smart contract used to coordinate payment, optional bonds, service completion, review and withdrawal for funded market-maker campaigns. It protects the commercial mandate under its contract rules; it does not guarantee a profitable trading strategy or successful external hedges.

How do Kuest market makers get paid?

A market maker can earn the campaign reward associated with an accepted liquidity mandate, subject to its terms and review, plus any trading P&L or eligible incentives from its own strategy. Spread capture, campaign payment and external-venue economics should be modeled as separate revenue lines.

Do Kuest market makers need approval?

Yes. Kuest market-maker campaigns are approval-based. The wallet is checked before acceptance, and the market maker should review the complete campaign terms before committing capital or a bond.

Does Kuest guarantee arbitrage returns?

No. Kuest provides shared infrastructure, market data, operator connectivity and escrow for liquidity campaigns. The market maker remains responsible for fair value, execution, inventory, hedging, capital and strategy risk.

Where can I find Kuest mirror-market campaigns?

Start on kuest.com/market-maker. Approved market makers can inspect open campaigns, including liquidity requirements, spread, duration, reward, bond and whether an external Polymarket hedge is available.