> ## Documentation Index > Fetch the complete documentation index at: https://txline-docs.txodds.com/llms.txt > Use this file to discover all available pages before exploring further. # Get a Merkle proof for fixture statistics > This endpoint provides a deep cryptographic proof for statistics within a single scores update. The TxODDS Oracle data is structured in a three-level Merkle hierarchy: 1. A main batch contains summaries for multiple fixtures. 2. Each fixture summary is the root of a sub-tree of all score update events for that fixture. 3. Each score update event is the root of a sub-tree of all the individual statistics it contains. This endpoint returns the full set of proofs needed to connect the stat(s) all the way to the main batch root published on-chain. ### Request Modes The endpoint supports two mutually exclusive request formats: * **Legacy Mode (`statKey`, `statKey2`)**: Returns a `ScoresStatValidation` payload containing proofs for one or two specific statistics. * **V2 Mode (`statKeys`)**: Accepts a comma-separated list of keys and returns a `ScoresStatValidationV2` payload supporting dynamic N-dimensional proofs across any number of requested statistics. ### On-Chain Execution With the returned data, the user can execute an on-chain transaction to validate that a supplied strategy holds against the extracted stats. For example, validating that a team's score exceeded a threshold, or that the difference between two scores meets a specific binary condition. ## OpenAPI ````yaml https://txline.txodds.com/docs/docs.yaml get /api/scores/stat-validation openapi: 3.1.0 info: title: TxLINE off-chain API for the Hybrid on-chain/off-chain TxODDS Data system version: 1.5.2 description: > ## Overview This API provides access to real-time and historical sports data from the **TxLINE on-chain/off-chain Data system**. It makes proprietary TxODDS available for any funded blockchain users by linking the on-chain `subscribe` transaction by issuing time-limited API tokens. - The data is canonicalised so that all fixtures, odds, or scores are provably identifiable and ordered--confirmed by on-chain cryptographic proofs. - The data is delivered in a request-response or Server-Sent Events (SSE) streaming form. Examples of accessing the accompanying on-chain program are available publicly at: https://txline.txodds.com/documentation. All data returned by the off-chain API is canonicalised such that every single record can be cryptographically proven on-chain to be part of the unique and consistent dataset generated by the TxODDS Data system. ## Key features * The odds data includes the `Stable Price` demargined prices and percentages, currently for key markets in European football (soccer). * **Free subscription option that offers World Cup 2026 odds and off-the-board signals in real-time sampled every 60 seconds**. * **Data access paid for by the TxLINE token tethered to USDT ata rate 1 USDT = 1_000 TxLINE tokens** The TxLINE utility token can purchased using the associated Solana program. * **Fine-grained service level selection** The user can list the pre-configured **service levels** that either map to pre-defined league bundles or allow custom selecting the leagues explicitly. The price also depends on the sampling period for the data. * **Maximum subscription option that offers all leagues in real-time**. * **Historical Snapshots:** Query the latest state of any market at a specific point in time. * **Historical Updates:** Query the updates for any given key such as fixture or market for a given time period. * **Live Data Streams:** Real-time, low-latency data feeds using Server-Sent Events (SSE). * **On-chain Validation:** Retrieve Merkle proofs to cryptographically verify data against the on-chain held Merkle roots by calling appropriate validate on-chain instructions. ## How do the users gain access to off-chain data (see more details and examples at: https://github.com/txodds/tx-on-chain) 1. For paid service tiers, the user purchases TxODDS TxLINE utility tokens for USDT at a fixed rate using either a script (e.g., calling `purchase_subscription_token_usdt`) or an affiliate website. The tokens are deposited into the user's associated token account. (Note: This step is skipped for the free World Cup tier). 2. As a guest, with no prior authentication, the user calls the off-chain API at "https://txline.txodds.com/auth/guest/start" (or `txline-dev` for DevNet) to obtain an anonymous JWT with Guest claims. **Please note that the JWT token has 30 days expiration so if you are issuing calls to the data endpoints beyond 30 days, you should either pre-acquire a new JWT token in time before 30 days expire or respond to the returned HTTP 401 code by reacquiring a fresh JWT token.** 3. The user creates, signs, and confirms a Solana transaction to the `subscribe` instruction, indicating the duration in weeks (must be a multiple of 4 weeks, e.g. 4, 8, 12) and the chosen service level. The user explicitly acts as the transaction fee payer. For the free tier, the smart contract registers the subscription but charges 0 TxLINE tokens. 4. The user records the confirmed transaction signature (`txSig`). 5. The user constructs a strict message binding consisting of the `txSig`, a comma-separated list of selected leagues, and the JWT. 6. The user cryptographically signs this message using their wallet's secret key to generate a detached signature, which is then Base64-encoded. 7. The user activates the subscription with the off-chain server at "https://txline.txodds.com/api/token/activate" (or `txline-dev` for DevNet) by posting the `txSig`, the Base64 wallet signature, and the selected leagues array, using the JWT for authorization. 8. The off-chain server validates the cryptographic proof and entitlements, issuing an appropriate API Token or rejecting the activation with a reason. 9. The user calls the documented APIs while the subscription is valid, supplying both the JWT and the API Token. 10. Before the subscription expires, the user may call the `subscribe` instruction again to extend the validity period (by a multiple of 4 weeks, e.g. 4, 8, 12) via the same off-chain activation call. The selected leagues can also be amended. 11. If the previous subscription has expired, the user can activate a new API Token by repeating the process. servers: - url: https://txline.txodds.com description: Production TxLINE server - url: http://txline-dev.txodds.com description: Test TxLINE server security: [] paths: /api/scores/stat-validation: get: tags: - Scores summary: Get a Merkle proof for fixture statistics description: > This endpoint provides a deep cryptographic proof for statistics within a single scores update. The TxODDS Oracle data is structured in a three-level Merkle hierarchy: 1. A main batch contains summaries for multiple fixtures. 2. Each fixture summary is the root of a sub-tree of all score update events for that fixture. 3. Each score update event is the root of a sub-tree of all the individual statistics it contains. This endpoint returns the full set of proofs needed to connect the stat(s) all the way to the main batch root published on-chain. ### Request Modes The endpoint supports two mutually exclusive request formats: * **Legacy Mode (`statKey`, `statKey2`)**: Returns a `ScoresStatValidation` payload containing proofs for one or two specific statistics. * **V2 Mode (`statKeys`)**: Accepts a comma-separated list of keys and returns a `ScoresStatValidationV2` payload supporting dynamic N-dimensional proofs across any number of requested statistics. ### On-Chain Execution With the returned data, the user can execute an on-chain transaction to validate that a supplied strategy holds against the extracted stats. For example, validating that a team's score exceeded a threshold, or that the difference between two scores meets a specific binary condition. operationId: getApiScoresStat-validation parameters: - name: Authorization in: header description: Bearer token for the user's session JWT. required: true schema: type: string - name: X-Api-Token in: header description: The user's long-lived API token. required: true schema: type: string - name: fixtureId in: query description: The ID of the fixture for the scores event. required: true schema: type: integer format: int32 - name: seq in: query description: >- The sequence number of the specific scores event within the fixture's history. required: true schema: type: integer format: int32 - name: statKey in: query description: >- Legacy Mode: The key identifying the specific statistic to validate (e.g., 1 for 'Participant1_Score'). required: false schema: type: integer format: int32 - name: statKey2 in: query description: >- Legacy Mode: The key identifying an optional second statistic to validate for two-stat predicates. required: false schema: type: integer format: int32 - name: statKeys in: query description: >- V2 Mode: Comma-separated list of stat keys used in N-stat validation strategies. required: false schema: type: string responses: '200': description: '' content: application/json: schema: anyOf: - $ref: '#/components/schemas/ScoresStatValidation' - $ref: '#/components/schemas/ScoresStatValidationV2' '400': description: >- Invalid value for: header Authorization, Invalid value for: header X-Api-Token, Invalid value for: query parameter fixtureId, Invalid value for: query parameter seq, Invalid value for: query parameter statKey, Invalid value for: query parameter statKey2 content: text/plain: schema: type: string '401': description: 'Authorization failed: Invalid or expired guest JWT' content: text/plain: schema: type: string '403': description: 'Access denied: Invalid API token or insufficient permissions' content: text/plain: schema: type: string '500': description: Internal server error content: text/plain: schema: type: string security: - httpAuth: [] apiKeyAuth: [] components: schemas: ScoresStatValidation: title: ScoresStatValidation type: object required: - ts - statToProve - eventStatRoot - summary - statProof - subTreeProof - mainTreeProof properties: ts: type: integer format: int64 statToProve: $ref: '#/components/schemas/ScoreStat' eventStatRoot: type: string format: binary summary: $ref: '#/components/schemas/ScoresBatchSummary' statProof: $ref: '#/components/schemas/List_ProofNode' subTreeProof: $ref: '#/components/schemas/List_ProofNode' mainTreeProof: $ref: '#/components/schemas/List_ProofNode' statToProve2: $ref: '#/components/schemas/ScoreStat' statProof2: $ref: '#/components/schemas/List_ProofNode' ScoresStatValidationV2: title: ScoresStatValidationV2 type: object required: - ts - eventStatRoot - summary - subTreeProof - mainTreeProof properties: ts: type: integer format: int64 statsToProve: type: array items: $ref: '#/components/schemas/ScoreStat' eventStatRoot: type: string format: binary summary: $ref: '#/components/schemas/ScoresBatchSummary' statProofs: type: array items: $ref: '#/components/schemas/List_ProofNode' subTreeProof: $ref: '#/components/schemas/List_ProofNode' mainTreeProof: $ref: '#/components/schemas/List_ProofNode' ScoreStat: title: ScoreStat type: object required: - key - value - period properties: key: type: integer format: int32 value: type: integer format: int32 period: type: integer format: int32 ScoresBatchSummary: title: ScoresBatchSummary type: object required: - fixtureId - updateStats - eventStatsSubTreeRoot properties: fixtureId: type: integer format: int32 updateStats: $ref: '#/components/schemas/ScoresUpdateStats' eventStatsSubTreeRoot: type: string format: binary List_ProofNode: title: List_ProofNode oneOf: - $ref: '#/components/schemas/Nil' - type: array items: $ref: '#/components/schemas/ProofNode' ScoresUpdateStats: title: ScoresUpdateStats type: object required: - updateCount - minTimestamp - maxTimestamp properties: updateCount: type: integer format: int32 minTimestamp: type: integer format: int64 maxTimestamp: type: integer format: int64 Nil: title: Nil type: object ProofNode: title: ProofNode type: object required: - hash - isRightSibling properties: hash: type: string format: binary isRightSibling: type: boolean securitySchemes: httpAuth: type: http description: User's session JWT. scheme: bearer apiKeyAuth: type: apiKey description: The user's long-lived API token, obtained from the activation endpoint. name: X-Api-Token in: header ````