The SDK We Built for Our Own Team — Then Deleted Our Own Code to Use It

Most of what a hackathon produces is apps — six of them went in tonight for the Superteam Earn × TxODDS World Cup hackathon, each with its own pitch and its own screen. This post is about the one entry that isn’t an app at all. TxLINE Kit is a TypeScript and Rust SDK for building on TxODDS’s live TxLINE sports-data feed — a typed client, deterministic match replay, cryptographic proof verification, and Solana on-chain settlement, packaged so the next project doesn’t have to rebuild any of it from scratch. TxLINE Kit and Proofline are both part of PulsePlay, our family of open sports-prediction tools — built by the same team, deliberately meant to interoperate.

The pitch for an SDK is always a little abstract next to a working app. So instead of describing what TxLINE Kit could do for someone else’s project, here’s what it already did for one of our own.

The proof that actually matters: we deleted our own code

Proofline is one of the other entries in this hackathon — a Solana adapter that verifies match outcomes on-chain against TxLINE. Its mainnet deploy commit tonight tells a small, specific story worth reading directly. Before, Proofline carried its own hand-rolled idl_types.rs module — 68 lines of code hand-parsing TxLINE’s on-chain instruction shape, the kind of brittle plumbing every team ends up writing once and then has to maintain forever. In that commit, the file is deleted outright. In its place, Cargo.toml picks up a single new dependency:

txline-kit-cpi = { path = "../txline-kit/crates/txline-kit-cpi" }

and the code that used to hand-roll a program ID now just reads:

pub const MAINNET_PROGRAM_ID: Pubkey = txline_cpi::MAINNET_PROGRAM_ID;

That’s the whole story in two diffs. Nobody asked Proofline to dogfood the kit — they deleted their own working code and replaced it with a path dependency on txline-kit-cpi because it was less code to own. A team’s own hand-rolled logic losing out to a shared crate, in a commit that also carries the real mainnet deploy evidence, is a better argument for an SDK than any README.

What’s actually inside

The kit is organized in layers, and each one is meant to be usable on its own:

• A typed client for TxLINE authentication, normalized score and odds data, and resilient server-sent-event streams.
• Deterministic .trec replay — record a match once, replay it byte-for-byte identically for testing, with a virtual clock and a CLI (txline-replay).
• A safe strategy compiler for building settlement predicates — it refuses to compile unless every requested stat is covered exactly once, so a market can’t accidentally read a stat it never validated.
• Merkle proof verification — fetch a proof bundle, walk the directional SHA-256 path, and check it against an on-chain anchored root, entirely read-only, no funds spent.
• txline-kit-cpi, the Rust crate — typed Anchor CPI bindings for TxLINE’s validate_stat_v2 instruction, pinned to a specific TxODDS IDL commit, that check return data comes from the exact expected program and decodes as one exact boolean before anything downstream trusts it.

The SDK is also honest about its own edges. verifyMerklePath recomputes a proof locally from an already-canonical leaf hash — but the docs are explicit that a full verifyLocal(bundle) isn’t offered yet, because TxLINE’s exact leaf-serialization format still needs reproducing against known roots first. That’s a deliberate refusal rather than a guess, and it’s the same posture the whole project takes: an ODDS_PROBABILITIES_UNAVAILABLE error instead of a silently wrong number, a PROOF_STAT_ORDER_MISMATCH instead of a proof checked against the wrong stat.

v0.2, shipped tonight, breaking nothing

Tonight’s release adds a documentation site and a repo-shipped onboarding skill for agents integrating the SDK, a proof lifecycle with explicit observed → canonical → verified → quarantined states, a canonical journal that deduplicates and reconciles records deterministically, a local Merkle tree builder, an impliedProbabilities() helper that normalizes odds (including TxLINE’s own milli-odds scaling) into a clean home/draw/away probability triple, and namespace-generic root-PDA derivation with timestamp-unit healing. An experimental odds-proof client is included too, clearly marked as unvalidated against live batch roots until it is.

None of that touches the part other programs actually link against. We checked the diff directly rather than take anyone’s word for it: between the v0.1.0 tag and tonight’s v0.2.0 tag, the txline-kit-cpi crate’s source is byte-for-byte identical — the only file that changed in that crate at all is its README. Anything built against 0.1’s on-chain interface, like Proofline, upgrades for free.

What it isn’t, on purpose

This is hackathon integration software, stated plainly in its own safety boundary doc: unaudited, no real-money wagering, no USDC custody anywhere in it. No credentials, wallet keys, or restricted raw feed data live in the repo, and the only match recordings that are public are synthetic ones — real match data stays private until TxODDS grants redistribution rights. Publication to npm and crates.io is deliberately deferred until a full clean-room registry install has been rerun and verified; for now, both packages install from source (git clone https://github.com/0xPulsePlay/txline-kit && pnpm install && pnpm build).

Try the interactive guide: txline-kit.claude.do — “See the match. Inspect the truth.” · source: github.com/0xPulsePlay/txline-kit