We publish trading figures from a live account, so the rules behind them matter as much as the figures. This page states what is measured, from which source, over what period, and where the numbers are weakest.

What we measure

Five quantities, each from a distinct source:

Liquidity rewards earned. Read from Polymarket's authenticated per-market reward ledger, the same figures the exchange uses to pay the account, plus maker rebates recorded separately. Not estimated from the public tape, which mislabels reward transfers.
Deployed capital. Free collateral, sampled from the account's live balance, plus the cost basis of every position the bot currently holds open. Both halves are counted because money tied up in inventory is money at stake.
Inventory and trading P&L. Realised profit and loss on the positions the bot picked up when its orders were filled, summed over the same window as the rewards.
Net P&L. Rewards minus that cost. Nothing else is netted out; there is no management fee or notional adjustment.
Rewards ÷ costs. The ratio of the first to the third. Above 1.0 the strategy nets positive over the window.

Rewards are not profit

This is the distinction the whole page exists to protect. A Polymarket liquidity reward is a payment for having quoted, and it arrives whether or not the quoting made money. When one of the bot's resting orders is filled it holds real inventory, and unwinding that inventory has a real cost. Gross reward income minus that cost is the only figure that describes whether the strategy worked.

Over the current trailing window that arithmetic is $349.45 of rewards against $479.35 of cost, a net of −$129.90. We publish both halves everywhere either appears, and the public stats API returns them in the same response so they cannot be quoted apart.

Measurement periods

The default window is the trailing 15 Polymarket payout days, currently ending with the most recent settled night.
Reward scoring runs over the UTC day and settles at 00:00 UTC. A payout therefore lands the morning after the trading day it covers, so rewards lag their own costs by roughly one day. Across a multi-week window that shift is immaterial; within a single day it is not, which is why we do not publish single-day net figures as headline numbers.
Today's accruing figure is an estimate in progress. It is never summed with settled nights or included in the window totals.
Yields are not annualised. A percentage on this site covers its stated window. Reward pools are split among competing makers rather than compounding, so extrapolating to a year would overstate them badly.

Limitations

Self-published, not audited. These are our own measurements of our own account. The reward figures originate in Polymarket's ledger and the payouts settle on-chain, so the income side is independently checkable; the accounting layered on top is ours and has not been reviewed by a third party. We do not describe these results as audited, because they are not.
Our sources do not perfectly agree. We reconcile reward income and trading costs across four independent readings: the trade ledger the dashboard renders, the strategy's own rescue ledger, the income tables, and on-chain activity for the account. As of the latest run those readings of all-time net differ by roughly $135, because a minority of on-chain fills are not yet matched to a ledger row. The figures published on this site are the trade-ledger readings, which are the least pessimistic of the set. We would rather say that than present a single number as settled.
One account, short history. A few thousand dollars over a few weeks, on a strategy that has been revised during the window. Results before and after a revision are not the same experiment.
Cost data is coarser than reward data. Rewards are attributed per market per day by the exchange. Our cost side is realised P&L on our own fills, which is accurate in aggregate but does not attribute cost to individual markets as precisely as rewards are attributed.
Survivorship of the strategy itself. Parameters have been tuned while the account traded. That makes recent performance partly in-sample.

When a published figure turns out wrong

We correct it in place and log the correction publicly with a date. Two figures on this site have already been corrected that way, including a rewards-to-costs ratio that had never been measured properly. The log is in the corrections section of the earnings write-up. Anything computable is now computed from the ledgers rather than typed by hand, which is what caused both errors.

Checking it yourself

The figures on the results page come from a keyless public endpoint. Query it directly and you get the same object the page renders, gross and net together:

curl -s https://clydescan.com/api/stats

Field-by-field definitions are in the API documentation. Polymarket's own reward payouts arrive as on-chain transfers, so the income side can be verified against the chain independently of anything we publish.