Ethereum type-checks bytes. This type-checks meaning.

Software constantly trusts other software's "proof", and routinely lets a weak one stand in for a strong one. That silent upgrade is the root of many "it was verified" failures: drained bridges, fake attestations, agents acting on claims nobody actually confirmed. Semantic ABI reads what each piece of evidence is allowed to prove and flags the mismatch (a signal of a possible exploit before it ships) with a concrete counterexample. Type-checking, but for trust.

for builders A commitment, an attestation, a state proof and an independent recomputation can each return true and still carry completely different authority. This is an executable type system for what one protocol's evidence is allowed to mean when another consumes it, so a composition can't silently upgrade what it proves.

semantic manifests→ typed relation graph→ semantic linker→ live / replay adapters→ protected-relation eval→ witness / counterexample

How it plugs in

Plug in with a small adapter, declare what your evidence may prove, and the zero-dependency runner checks the composition. No rip-and-replace, and every system that joins strengthens the standard. It doesn't replace your stack. It becomes the spine between its parts.

Meet the agent, then drive it, the runner and the proof reveal in sequence.

Genesis Agent · action chat (reference flow)● identity + PQ real

Trustless Pioneer

agent #1 · from trustless-ai

0xe919…4963 #1 · GenesisAgentRegistry · owner 0xFf9a…ca14

Post-quantum bound · ERC-8373

ML-DSA-65 · Dilithiumpq_key_binding.v0

owner-authorized ML-DSA-65 delegate · secp256k1 owner sig ✓
binding recomputable · anchored · Base Sepolia (epoch 4)
per-action companion signing, roadmap (Phase 3)

Drive me, every reply emits typed evidence: an Evidence<…> receipt the linker and the relation-runner can consume.

the agent driving this

Trustless Pioneer, securing its past and its future

A pre-action runner: before it acts it commits what it is about to do, and its identity is bound to a post-quantum key anchored in time on-chain, so its record can't be forged forward or backward. Drive it, and two independent systems check that record against one standard.

1 · publish

Declare the key

The agent's post-quantum key is published as pq_pubkey.

2 · anchor

Stamp it in time

Its hash is stamped on Ethereum. Hashes are quantum-safe, so the anchor is a provable, unforgeable time of existence.

3 · enforce

Draw a cutoff

A strict cutoff T a retroactive forger cannot cross, no back-dating the record.

Protected-relation runner · 2 levels, kept separate · check it: node runner/demo.mjs ↗

SubjectEvidence<…> , feed tampered evidence

Protected relation	invinoveritas @babyblueviper1 adapter + vectors ↗	Vértice gw @TMerlini adapter + vectors ↗

, observed pair · preserved / violated / unverifiable

, conformance · pass / fail / cannot-check

no shared checker · 2 repos (horizon-shield post-event)

invino C1

expected = the oracle (what the pair should read) · observed = what the backend reported · conformance = observed == expected? three separate values, never fused, PRESERVED / VIOLATED / UNVERIFIABLE for the pair, PASS / FAIL / CANNOT_CHECK for conformance. tampered input → expected VIOLATED; a correct backend observes VIOLATED and conforms (PASS). FAIL = expected VIOLATED but observed PRESERVED, the distinction collapsed.

Can one system's proof be used by another? · checked live by the real runner

One system proves

Another system wants to rely on

Pick what one system proves and what another wants to rely on (or try a preset). It answers whether that's a fair use of the evidence, or shows you exactly why it isn't.