CoreTex Client Architecture

CoreTex is the open client for BOTCOIN's retrieval-memory lane. In practical terms, it plays the role that Bitcoin Core plays for Bitcoin: it carries the code, manifests, corpus bindings, model pins, replay rules, and local verifier tooling needed to independently check the state transitions that the coordinator awards.

It is not a hosted model and not a private benchmark service. The coordinator runs CoreTex to evaluate submissions in real time, but the same pinned bundle is available to miners and independent verifiers. The chain stores roots, accepted compact patches, receipts, and epoch metadata. The CoreTex client turns those public commitments back into decoded substrate state and benchmark results.

The architecture separates three concerns:

That separation is intentional. The EVM should not run retrieval models, and miners should not have to run the whole calibration stack to participate. At the same time, accepted state advances must remain replayable by anyone who does run the client.

The design was chosen around four constraints:

• Keep settlement small enough for Base by anchoring roots, receipts, patch bytes, and epoch metadata on chain.
• Keep evaluation strong enough to measure retrieval quality by running the benchmark off chain under a pinned client bundle.
• Keep miner participation lightweight by serving current state, visible corpus views, and live coarse results through the coordinator API.
• Keep verification independent by making the same bundle, corpus roots, model manifests, patch bytes, and replay rules public.

What Ships In The Client Bundle

A CoreTex release is not just an NPM package. The bundle is the versioned verifier surface for an epoch. It contains or pins:

The minimum useful validator setup is deliberately small:

1. Install the CoreTex client release.
2. Provide a Base RPC URL.
3. Point the client at the active contract addresses.
4. Let the client fetch or verify the active bundle and corpus artifacts by hash.

Validators do not need to generate the corpus, label qrels, tune thresholds, or train models. Those are release and calibration tasks. A validator only needs the published artifacts and enough local compute for the verification depth it chooses.

A light verifier can check patch bytes, state-root continuity, bundle/corpus hash binding, and receipt structure without running the models. A full evaluator replay also runs the pinned CPU model path and reproduces gate/confirm scores within replayTolerancePpm. Both paths are useful: the light path catches impossible chain histories; the full path catches scoring drift.

Client Releases And Version Policy

CoreTex client artifacts ship as versioned GitHub releases. Each release publishes the coretex-replay and botcoin-cortex binaries plus a tarball, accompanied by SHA256SUMS and a release manifest for integrity verification.

Bundle manifests can pin a clientVersionPolicy block that gates which client versions are accepted against the active bundle:

Runtime behavior:

• A client below minimumVersion is flagged OUTDATED_CLIENT.
• When hardFailOutdated is true, the client refuses canonical evaluation. An explicit emergency override flag exists for continuity during incidents.
• A client at or above minimumVersion runs normally; recommendedVersion lag is logged but not blocking.

Startup binding is fail-closed on explicit signal and tolerant on absence:

• Outdated or invalid client versions are refused.
• Bundles without a clientVersionPolicy do not brick existing validators — the policy is opt-in per bundle, so a missing field never breaks a live fleet.

Recommended rollout for a new minimum version is phased: warn-mode publication first, fleet audit to confirm validator uptake, then hard-fail enforcement in the next bundle rotation. Operators updating to a release that crosses a minimumVersion boundary install the new artifact, verify against SHA256SUMS, and restart the client.