Position Tracking and PnL for Binary Event Contracts

A position record answers several different questions: what is held, what it cost, how it is marked, what it could pay under the rules, and what cash has actually arrived. Combining those questions into one unlabeled P&L number makes a paper result difficult to interpret.

This article's calculator covers one fully paid long outcome. For an ordinary binary payout, a winning contract pays $1 and a losing one $0. Scalar or exceptional payouts need their own settlement value. Do not infer the payout solely from a YES/NO label or assume every product has the same collateral model.

Keep quantity and money separate

Store exact market and outcome identifiers, held contract quantity, acquisition cost and fees. Preserve deposits, withdrawals, sales and adjustments in a separate cash ledger. A deposit increases cash without being a trading gain.

An order request is not a position. Partial fills add only the completed quantity; uncertain cancellations remain contingent exposure until reconciled. A negative signed quantity is not automatically a lawful naked short. Buying NO and selling held YES are different account actions even when their ordinary-binary exposures are related.

Label each valuation view

A last trade, midpoint and estimated executable sale proceeds answer different questions. A bid can support an exit estimate for the available quantity; it does not guarantee that a larger position can be sold at that price. Keep the timestamp, size and chosen mark convention beside the value.

Kalshi's portfolio guidance distinguishes cash and displayed position value, and explicitly notes that displayed value is not guaranteed sale proceeds. A model-dependent mark is still useful when clearly labeled. An unknown or stale mark should remain visible rather than being silently replaced with a confident liquidation estimate.

Calculate a limited example

The standalone function below reports marked P&L and ordinary-binary scenarios. It treats remaining cost as already including allocated entry fees. It does not deduct those fees again, and it does not call a settlement claim realized cash.

from decimal import Decimal


def paid_long_views(quantity, remaining_cost, mark, settlement_value=None):
    # One fully paid held outcome; remaining_cost includes allocated entry fees.
    # No closes, deposits, borrowing, taxes or account reconciliation modeled.
    qty, cost, m = map(lambda x: Decimal(str(x)),
                       [quantity, remaining_cost, mark])
    if not all(x.is_finite() for x in [qty, cost, m]):
        raise ValueError("inputs must be finite")
    if qty < 0 or cost < 0 or not 0 <= m <= 1 or (qty == 0 and cost != 0):
        raise ValueError("invalid paid-long record")
    result = {"marked_pnl_usd": qty * m - cost,
              "if_binary_win_usd": qty - cost,
              "if_binary_loss_usd": -cost}
    if settlement_value is not None:
        value = Decimal(str(settlement_value))
        if not value.is_finite() or not 0 <= value <= 1:
            raise ValueError("invalid settlement value")
        result["settlement_claim_pnl_usd"] = qty * value - cost
        # A claim value is not evidence that cash has been received.
    return result


print(paid_long_views("100", "41", "0.92"))
# Marked: 51; binary win: 59; binary loss: -41. Hypothetical USD amounts.

The hypothetical 100-contract holding cost $41 including its assumed entry fee. A $0.92 mark produces $51 marked P&L. A $1 payout produces a $59 claim gain; a zero payout produces a $41 loss. These are arithmetic scenarios, not a forecast of the event or an executable offer.

Book partial closes consistently

Choose an explicit cost-allocation convention and preserve it across acquisitions and reductions. For each completed sale, allocate the corresponding entry basis, subtract exit costs once and retain the basis of the remaining contracts. This toy function does not implement that ledger.

Realized and unrealized P&L can be summed into a labeled total under a consistent accounting convention. The problem is missing definitions or double-counted fees, not the mere existence of a total. Explain whether entry fees were booked immediately or included in remaining basis before comparing two reports.

Resolution and cash arrival are separate

An apparent event result, the venue's determination, a redemption claim and a credited cash payout need not occur together. Use the exact rules and authoritative settlement records. Current Polymarket documentation describes more than one resolution mechanism; do not hardcode UMA or a universal two-hour completion.

Kalshi's settlement API includes payout and fee fields, and describes a rounding adjustment in its scalar example. Preserve the actual report and avoid subtracting a fee already included in a net payout. The generic binary scenario calculator is not a complete venue ledger.

Read Banger accounting as implemented

In Banger's public 0.1.7 forward-paper package, entry fees reduce its realized accumulator immediately; the average position price excludes that fee. Marks can use an exit-side quote with a fallback. That convention differs from the calculator's fee-inclusive remaining basis, so do not present this snippet as Banger's internal accounting.

The packaged daily-loss control uses mark-to-market changes from a UTC-day baseline, rather than the worst-case-settlement calculation previously claimed here. Fee policy and assumed passive fills are also mode dependent. Banger's public beta is paper-only: inspect the exact result model and preserved history without assuming identical real-money behavior.