TTTPS: Byzantine Audit API

One cryptographic proof chain, regulator-ready audit across jurisdictions: tamper-rejecting at ingress, tamper-evident after write, operator-independent.

EU AI Act GPAI/Art.53 · Aug 2, 2026 (confirmed) · high-risk (Art.12) deferred to Dec 2027 (Digital Omnibus, provisional)

The Problem

Distributed systems (inference clusters, CDN networks, payment processors, telco signaling) lean on timestamps to sequence events, block replays, and satisfy regulators. But one clock is one point of trust. Compromise the NTP server, spoof the GPS signal, inject a false clock update, and the entire audit trail is corrupt. Traditional systems catch it after the fact, or never.

TTTPS closes this at the protocol level. Every attestation anchors to multiple independent time sources at once: NIST Roughtime and network time; GPS and Equinix PTP (±1µs, SVC target); GEO/KTSat ±10ns (roadmap), bound into a cryptographic commitment chain. Manipulate one source and the others disagree, detected instantly. Replay the same token and the chain registers a verifiable collision.

Overview

Most systems trust a single clock. Wrong by drift, or compromised by NTP injection or GPS spoofing: the whole audit trail goes with it, and nothing inside the system can tell.

TTTPS anchors every token to multiple independent sources at once: NIST Roughtime and network time; GPS and Equinix PTP (±1µs, SVC target); GEO/KTSat ±10ns (roadmap), across one commitment chain. Manipulate one and the rest disagree. The divergence is logged with the exact attack type, so the trail survives even under active attack.

Replay is just as visible: submit a token twice and the chain collides on the second verify. No trust in the submitter, no trust in the network: only that the commitment is internally consistent.

Why tampering doesn't work

Three independent layers close every angle of attack, from the moment a token arrives to the moment a regulator reads the log.

Attack Detection Capability Matrix

7 attack vectors actively detected (6 on roadmap) via cryptographic commitment chain and temporal verification.

Lattice Commitment Pipeline

Multi-stage cryptographic commitment architecture. Each stage narrows the attack surface.

The pipeline ingests independent time sources: NIST Roughtime, network time; GPS and Equinix PTP (±1µs, SVC target); GEO/KTSat ±10ns (roadmap), and computes a layered commitment, sealed with an Ed25519 signature over the final chain digest. Tamper at any stage, by any vector, and verification returns a mismatch.

SealingSwitch: Turbo / Full

Adaptive sealing mode based on time-source quality.

Note: internal pipeline architecture proprietary. Contact info@kenosian.com for technical deep-dive under NDA.

Real-World Attack Scenarios

How TTTPS catches attacks that traditional audit systems miss entirely.

Live Demo · No API key required · Rate-limited

Or via curl:

Step 1: Generate a token

curl -X POST https://api.kenosian.com/api/demo/pot/generate \
  -H "Content-Type: application/json" \
  -d '{"ctx_id":"demo"}'

Expected response:

{
  "status":         "ok",
  "ctx_id":         "demo",
  "timestamp_ms":   1748000000000,
  "lattice_commitment": "a3f9c2...",
  "chain_digest":   "b7c2e1...",
  "signature":      "ed25519-base64...",
  "pubkey":         "acac8eae..."
}

Step 2: Verify (replay attack detection)

curl -X POST https://api.kenosian.com/api/demo/pot/verify \
  -H "Content-Type: application/json" \
  -d '{"ctx_id":"demo","token":"<paste token from step 1>"}'

Step 3: Trigger replay detection

# Submit same token twice → REPLAY detected
curl -X POST https://api.kenosian.com/api/demo/pot/verify \
  -H "Content-Type: application/json" \
  -d '{"ctx_id":"demo","token":"<same token>"}'

{"valid":false,"attack_type":"REPLAY"}

Audit Log

curl "https://api.kenosian.com/audit?ctx_id=demo&window=3600" \
  -H "X-API-Key: <your-key>"

Response (real measurement basis):

{
  "ctx_id": "demo",
  "window_secs": 3600,
  "total_requests": 142,
  "byzantine_total": 3,
  "byzantine_ratio": 0.021,
  "attack_breakdown": { "REPLAY": 2, "DRIFT": 1, "FORGE": 0, "FLOOD": 0 }
}

Prometheus metrics:

curl https://api.kenosian.com/metrics

tttps_attack_total{type="replay"}   2
tttps_attack_total{type="drift"}    1
tttps_byzantine_ratio               0.021

API Coverage · Self-serve key, no card · Live Scalar console

The self-sealing receipts service below is the live API documented at api.kenosian.com/openapi.json. Each card opens the matching endpoint directly in the Scalar console with a working request panel: same server, same schema, no separate sandbox.

When to Use TTTPS

TTTPS is the right tool when you need to prove when something happened, not just that it happened.

Built on TTTPS

TTTPS is not a standalone product line running in parallel to the Hydra family: it is the timing-integrity root of trust underneath it. Each product below anchors its own domain-specific proof to the same TTTPS commitment chain; none of them ship their own competing timestamp layer.

• Hydra-CDN: per-chunk delivery proof for CDN and game-patch distribution, sealed with TTTPS proof-of-time tokens on every chunk.
• Hydra-Audit: EU AI Act Art.12/53 training-data provenance and tamper-evident audit export, built on TTTPS timing integrity.
• Hydra-KV: cryptographic audit trail of KV cache transfers between prefill and decode nodes, sealed with the same TTTPS chain. Product page temporarily private during redesign.

TTTPS is the root of trust; the Hydra products are what running it in production looks like.

Regulatory Alignment

TTTPS provides cryptographic proof-of-time designed to satisfy timestamp integrity requirements across financial and infrastructure regulations.

Compliance & Audit Export

TTTPS generates a tamper-evident audit trail suitable for submission to regulatory bodies.

How to Deploy

Three questions a client asks: where does it attach, where is it served, and what do I actually implement. Concretely:

1 · Where it attaches

TTTPS binds to one layer of the transaction: pre-settlement ingestion, the moment an event enters the books, before it is committed. You do not modify the asset, the chain, or the settlement value. You seal the timing and order at the gate. Attach it to a stablecoin settlement flow and that stablecoin carries a tamper-rejecting record of when and in what order every transfer cleared: an integrity layer on top of an existing token, not a new token.

2 · Where it is served

The verification engine runs off-chain, on a data-center fabric, co-located with the systems that move at payment and inference speed. It can be served on a DC fabric (e.g. Digital Realty or Equinix Fabric) or self-hosted; either is supported, neither is a precondition. An on-chain anchor is optional: commit a periodic chain digest on-chain when you want long-lived public anchoring for audit, and skip it when you do not.

What it is not: an Ethereum-only deployment. Settling integrity proofs through block confirmation alone inherits block latency, seconds not microseconds, which is unfit for real-time payment and agent settlement. TTTPS runs at fabric speed and treats the chain as an optional anchor, not the critical path.

3 · What you implement

Three steps, dropped into the existing flow, no chain change, no reissuance:

Deployment

Open-source reference implementation. IETF draft in active submission.

npm install openttt

GitHub: github.com/helm-protocol/openttt
IETF Draft: datatracker.ietf.org/doc/draft-helmprotocol-tttps/
Production API: info@kenosian.com

Target Deployment: Equinix Fabric Tenants

Target accounts on Equinix Fabric, illustrative, pre-engagement (LOI stage). Revenue figures are estimated potential ARR, not contracted.

Tier 1: Institutional  ·  €12,000/mo

Tier 2: MiFID Pro  ·  €3,600/mo

Target PoPs: LD4 · FR5 · AM3 · NY4 · NY2 · CH1 · SK1 · HK1 · TY3 · TY5 · SV1, leveraging Equinix Fabric's global footprint.

Pricing

Fixed monthly subscription: up to 50M events/month (fair-use). All tiers include Byzantine detection, multi-source Roughtime validation, and audit log retention.

Market reference: DigiCert timestamp authority $0.10–0.50/token. TTTPS: up to 50M events/month (fair-use cap) with multi-source Roughtime + Byzantine detection included.
Annual contract: 2 months free.  ·  Included in all Hydra product bundles.  ·  Hydra-Audit: standalone or bundled (Contact).

API Access

Production API key required.
Contact info@kenosian.com for access and onboarding.

Trust Mark

Proposed mark for explanation only. Any “sealed” status is conditional (“could / if adopted”) and would operate under the Kenosian root of trust, not a present-day certification program.