Status

Methodology version 0.2.0. Every page shows which data the dashboard is using: a labelled demo dataset, an unavailable state, or live data from TicketSoft’s production event contracts on Base. All three follow these rules; switching data changes the source, not the definitions.

Source labels

  • On-chain: derived from specified production contracts and reproducible blockchain records.
  • Reconciled: blockchain records matched against private operational or payment records using a documented process.
  • Company-reported: supplied by TicketSoft with a stated reporting date and supporting basis.

A metric is never called independently audited without an audit covering that metric and period. Public verifiability of a mint is not proof of revenue, paid demand or attendance.

Common rules

  • Counts are limited to a verified production contract registry on Base mainnet. Testnets are excluded and production tests are identified.
  • All timestamps are UTC. Chart days are calendar UTC days.
  • Indexed events are identified by chain, block hash, transaction hash and log position. Provider retries are deduplicated and removed or reorganised logs are handled.
  • The confirmation state shown for a transaction (Included, Safe, Finalized or Unknown) comes from the source’s verified chain status under a stated finality policy. It is never inferred from elapsed time.
  • Transaction counts, token counts, order counts and real people are kept separate.

Tickets minted

Ticket tokens created in qualifying production mint events, counted gross and cumulatively through the source checkpoint. Each ticket TicketSoft issues is minted to its holder when it is issued, so the count covers paid, free and season tickets alike; it is not the number of paid tickets. Replacement mints and complimentary tickets are included in the gross count and disclosed where the data supports it. Transfers, scans, event registrations and discovery listings are not mints. A burn does not erase the historical fact of a mint.

Events created onchain

Unique production event registrations from the verified registry or factory contracts. Several deployments representing one business event are identified as one where the relationship is known. Test deployments are excluded. This is not the number of third-party events indexed by any discovery aggregator.

Minting costs

For each relevant transaction the full charged chain fee is captured, including Base execution and L1 data charges, from receipts rather than current gas estimates.

Two measures are kept apart:

  1. Successful-mint chain cost per ticket: chain fees allocated to successful ticket mint operations divided by the number of tickets those operations minted. This is the dashboard figure.
  2. Operational issuance cost per ticket: attributable issuance costs including failed attempts and separately identified service charges, divided by successful tickets. This is not on the dashboard yet.

Mixed transactions (for example one event registration plus several mints) allocate the transaction fee across operations under a documented method. A batch fee is never charged to every ticket, and paymaster or bundler charges already recorded elsewhere are not counted twice.

The displayed window average is sum(allocated cost) / sum(minted quantity) over complete UTC days, not the mean of daily averages. With no successful mints the average is undefined and shown as unavailable, even when the complete mint count is zero.

Fees are kept in ETH base units and converted using a timestamped rate for each day or execution. Lifetime expenditure is never revalued at today’s price. When a rate is missing the ETH figure remains available and the fiat conversion is shown as unavailable rather than zero.

Network costs are not total operating costs. Payment processing, engineering and general infrastructure are excluded.

Windows

Let D be 00:00 UTC on the source reference day. For the 30-day range the chart and cost window is the 30 complete days ending at D. The activity feed starts at the same point and extends through the latest source checkpoint, so it includes today’s records. Lifetime totals include canonical records through the relevant module checkpoint and do not change with the range.

Data states

  • Unavailable: no value, with the reason. A missing value is never shown as zero.
  • Partial: known scope and coverage dates are shown; a partial count is never labelled all time.
  • Stale: the last successful data is kept with its original as-of time.
  • Complete empty: zero totals appear only when coverage proves absence.
  • Correction: affected records are replaced from the canonical snapshot with a visible notice.

Required metadata

Each published metric carries its unit, source label, coverage, measurement window, generated timestamp, last indexed block or time, methodology version and data-quality state.

Limitations

The reporting frontend never reads customer databases or holds signing keys. Live counts use the reviewed registry of production event contracts, their creation records, the full fee from each transaction receipt, an hourly ETH/USD rate for the hour of each block, and Base’s safe head as the finality point, refreshed every hour. The activity feed lists each qualifying transaction with its hash, block, quantity and fee, and links to BaseScan; it does not list holder wallets or token ids, though anyone following a hash can see them on the public chain.