Prediction-Market Fees Explained: Polymarket vs Kalshi

A fee comparison needs an exact market, execution role, quantity and date. A headline percentage or an old category table is not enough. Keep the venue charge separate from spread, slippage, funding costs and rebates so a result can be reproduced.

An order's form does not by itself establish maker treatment. A limit order may execute immediately; a single request may have different execution behavior across its fills. Model the observed or explicitly assumed role rather than calling all limits free.

Save the authoritative rule

Check the current official schedule and any market-specific multiplier or exception. Preserve a dated copy or reference with the test. For historical research, a current rule is a sensitivity scenario unless it was actually in force during the period studied.

As checked October 13, 2026, Kalshi's official PDF shows a general taker component with coefficient 0.07 and a contract multiplier, plus a separate maker schedule. It specifies rounding of fee plus position cost to centicent precision. The display table alone is not a complete rounding algorithm.

Polymarket international's current fee page specifies market/category parameters, maker-versus-taker treatment and five-decimal fee precision. It does not support the earlier article's assertion that all sell orders escape taker charges. Do not copy these international rules into the separate US product.

Compute a component with explicit units

The standalone calculation below returns the unrounded component C × rate × p × (1 - p). C is contract quantity, p is dollars per ordinary $1-payout contract and rate is an explicitly supplied coefficient. It does not fetch market settings, infer maker status or reproduce the charged ledger amount.

from decimal import Decimal


def raw_fee_feature(contracts, price, rate):
    # A raw arithmetic component, NOT an exact venue invoice or rounding rule.
    c, p, r = map(lambda x: Decimal(str(x)), [contracts, price, rate])
    if not all(x.is_finite() for x in [c, p, r]):
        raise ValueError("inputs must be finite")
    if c < 0 or r < 0 or not 0 <= p <= 1:
        raise ValueError("invalid quantity, price or rate")
    return c * r * p * (1 - p)


print(raw_fee_feature("100", "0.50", "0.07"))  # 1.7500
# Assumed rate and quantity. Rounding, role and market rules are separate.

The assumed 100-contract, $0.50 example produces $1.75 before any rule-specific rounding or exceptions. Keep that dollar amount distinct from a percentage of stake. With the same quantity and coefficient, p and 1 - p produce the same raw component; different markets or execution roles need not have the same charge.

The function was checked offline for its illustrative arithmetic, zero quantity/rate, price symmetry and invalid inputs. A successful calculation is not evidence of a filled order or an exact venue invoice.

Compare paths rather than promising cheap trades

An early sale, a settlement payout and a passive order left unfilled are different paths. Apply the rule to each actual or simulated fill, including exits where applicable. Avoid a blanket statement that every round trip pays twice or that every maker receives a rebate.

A rebate is an additional program outcome with its own conditions; it is not a guaranteed reduction in the charge on every quote. Record it separately when supported by evidence. Likewise, a lower raw fee near a price bound does not establish a better strategy: payout risk, estimation error and available size still matter.

Rounding needs the full context

Quantity precision, partial executions, aggregation and position cost can affect the final charge. Match the documented operation, not a float shortcut or the displayed cents in an example. If a feed provides the actual fee, preserve it and reconcile it once.

An unavailable fee rule should be marked unknown. Show a stated sensitivity assumption if useful, but do not silently report a net result as accurate. A fee-only calculation also leaves spread and fill uncertainty unresolved.

Check the Banger model independently

The public Banger 0.1.7 package names its standard Kalshi simulation fee model and rounds that implementation up to a whole cent. Its optional forward-paper fee policy selects that model for Kalshi; it does not implement the current Polymarket category table. This is an observable simulation limitation, not proof that every mode is fee-free or exactly venue matched.

The forward-paper path also includes assumed fills at non-crossing limits. Banger's public beta is paper-only, so retain the fee/model identifier and result assumptions with the experiment. Interpret an apparent improvement under those assumptions; do not call it earned net profit or recommend committing real capital.