OpenPoly logo
Polyflight

Terms, statements, and settlement

Read commercial terms and reconcile native-IDR fee, signed position, liabilities, payments, carry, and exports.

Terms, statements, and settlement

Polyflight accounting is a dedicated native-IDR subledger. It is not the Opinion monthly settlement formula and it does not post Polyflight tickets into the central Finance USD trade-fee ledger.

Read-only commercial terms

Two independent percentages apply to an admitted ticket:

TermBaseDefaultAllowed range
Ticket fee shareThe ticket's 5% fee100%50%–100%
Position shareFee-exclusive signed game result80%50%–100%

Both values use basis points, accept a 100-BPS (one percentage point) grid, and are stored on an append-only terms version. Polynion receives the residual of each base. Account-manager allocations do not apply.

The operator Terms page exposes:

  • Current terms effective for newly admitted tickets now.
  • Scheduled terms for the next settlement-month boundary, if present.
  • History with revision, actor, reason, recorded time, effective time, old/new terms, and any superseded scheduled revision.
  • Settlement timezone, fixed when Polyflight was first enabled.

Only Polynion administrators can schedule terms. Operator API wildcard access remains read-only. Replacing a future schedule adds history rather than erasing the earlier revision. A ticket keeps the terms version captured at admission for both its eventual result and any cancellation adjustment, even if it lands in a later month.

Fee and signed position are different

For each admitted ticket:

fee base = feeMinor
position base on loss = netStakeMinor
position base on win = netStakeMinor - potentialPayoutMinor

The position base is signed and has no zero clamp or discretionary loss carry-forward. The ticket fee is allocated independently; winnings are already included in the signed position base and must not be subtracted again.

With the default 100% fee share and 80% position share, a 10,000 IDR ticket has fee 500, net stake 9,500, and winning payout 38,000:

Losing ticket — positive position

SectionBaseOperatorPolynion
Ticket fee+500+5000
Position+9,500+7,600+1,900
Total entitlement+8,100+1,900

The operator owes Polynion 1,900 IDR for this ticket's current-period allocations.

Winning ticket — negative position

SectionBaseOperatorPolynion
Ticket fee+500+5000
Position−28,500−22,800−5,700
Total entitlement−22,300−5,700

The negative Polynion entitlement means Polynion owes the operator 5,700 IDR. The 38,000 IDR user payout is not deducted a second time.

Zero aggregate position

One 10,000 IDR win has a −28,500 position base. Three 10,000 IDR losses contribute +28,500, so the four-ticket aggregate position base is zero. Fees remain a separate +2,000 base. At 100% fee share, the operator receives the 2,000 fee allocation and the position allocation is zero for both parties.

These examples omit fractional carry and previous balances so the bases are visible. Statements calculate over the full operator month, not per ticket.

Recognition timing

  • Confirmed debit first records wallet clearing and equal unadmitted-purchase suspense.
  • Admission reclassifies that suspense into fee entitlement and open net stake; it does not count cash again.
  • Result recognizes the signed position at the authoritative reveal time, even when the payout is delivered later.
  • Cancellation reverses the original fee/open stake and establishes the exact refund liability. It creates no position result.
  • A confirmed credit or reversal records wallet clearing and extinguishes its liability; it does not recognize income again.
  • Planned, sent, failed, ambiguous, or manually reviewed effects remain visible and do not pretend money moved.

A confirmed debit rejected after the gate has no ticket, terms, fee, or position income. It remains compensation payable until the exact debit reversal is confirmed.

Monthly statement lifecycle

Statement months use the fixed Polyflight settlement timezone and half-open UTC boundaries. Operators can read:

  • current activity/liabilities through the Polyflight overview and reporting lists;
  • immutable finalized statements;
  • statement detail and terms-version breakdown;
  • immutable payment history and statement-applied adjustment totals;
  • the matching canonical export.

Finalization occurs only for a completed month, in chronological order, after applicable result/void processing is complete and ambiguous wallet effects are reconciled. Known unpaid win, refund, or compensation obligations may remain if shown explicitly. Unknown cash state blocks statement finalization, not global flight progress.

A finalized statement is never regenerated from current terms. A late event whose economic time belongs to an already finalized month appears as an additive correction in the next open statement with original-period linkage.

Final statements include revisionIdentity, canonical statementDigest, signatureVersion, signerKeyVersion, signature, finalizer/reason/time, and the immutable input event IDs/digest/watermark. Retain those fields together. The operator reporting API does not expose a signing key endpoint; use the signer-key distribution and verification procedure supplied during onboarding. Do not treat transport TLS or a webhook signature as the statement signature.

Fractional rounding carry

Shares are calculated in numerator units of $1/10{,}000$ IDR and summed by operator, month, section, and terms version before conversion to IDR:

fee operator numerator = sum(feeMinor × ticketFeeShareBps)
position operator numerator = sum(positionMinor × positionShareBps)
T = opening fractional remainder + period operator numerator
operator allocation = truncTowardZero(T / 10000)
closing fractional remainder = T - operator allocation × 10000
polynion allocation = section base - operator allocation

Fee and position carry are separate signed values, each strictly between −10,000 and +10,000 numerator units. The statement shows opening carry, current numerator, rounded allocation, and closing carry. This is rounding carry, not an economic loss carry-forward.

Statement balance and direction

operator entitlement = operator fee allocation + operator position allocation
polynion entitlement = polynion fee allocation + polynion position allocation

A positive Polynion entitlement means the operator owes Polynion. A negative Polynion entitlement means Polynion owes the operator. The statement shows current-period earnings separately from:

  • prior unpaid statement balance;
  • payments already recorded;
  • explicit audited adjustments;
  • unadmitted-purchase suspense;
  • open stakes;
  • compensation, winnings, and refund liabilities;
  • confirmed wallet-clearing receipts and outflows.

The canonical statement fields expose fee and position allocations separately (baseMinor, operatorNumerator, opening/closing remainder, and both party allocations), cashClearing (receiptsMinor, outflowsMinor, netMinor), openingLiabilities / closingLiabilities, prior balance, applied payments/adjustments, settlementNetMinor, transferDirection, and transferAmountMinor. Aggregate money is serialized as decimal strings.

cashClearing contains confirmed wallet movements only. It reconciles cash against obligations and must remain separate from earned fee/position allocations; never count the same debit, credit, or reversal as revenue a second time.

Payments and exports

Interparty settlement is manual. There is no automatic bank transfer. Authorized Polynion administrators can record a partial or full payment with date, IDR amount, direction, reference, evidence, actor, and reason. Operators can read immutable payment history and the remaining balance. Correcting a mistaken payment uses an additive audited correction; it does not rewrite the original record or create revenue a second time.

CSV/download exports use the same canonical statement data as the dashboard and operator API. Reconcile decimal-string aggregate amounts exactly; do not parse large report totals through floating-point arithmetic. Confirm the selected operator, local month, timezone, final status, and revision before comparing an export.

Copyright © 2026