On-Chain Signal Attestation

Every day, TRADEOS.tech commits a cryptographic fingerprint of its signal activity to Base L2 — a public, immutable blockchain. This is not a marketing claim. It is a verifiable proof that the system ran, generated signals, and operated exactly as described.

Any independent party can verify that a specific signal was part of a specific day's trading session without accessing the production system, the database, or any private credentials.

---

Why it matters

Most trading systems ask you to trust their reported performance. TRADEOS.tech does not.

Signal attestation creates an independently verifiable audit trail anchored to a public blockchain. The on-chain root cannot be altered retroactively. The inclusion proof for any signal can be verified by anyone with the signal's metadata. This is cryptographic accountability — a standard that virtually no algorithmic trading platform meets.

For institutional operators and auditors, this means:

• Performance claims are anchored to immutable on-chain records
• No single party (including TRADEOS.tech) can modify historical signal data without detection
• Verification does not require access to production infrastructure

---

How it works

Step 1 — Build the daily Merkle tree

At 00:05 UTC each day, the attestor service fetches all signal outcomes recorded during the previous UTC day. For each signal, it computes a SHA-256 leaf hash from five fields:

leaf = SHA256(signal_id | timestamp | direction | confidence | symbol)

These leaves are assembled into a binary Merkle tree. Duplicate-last padding ensures the tree is always balanced. The Merkle root is a 32-byte SHA-256 digest that commits to the complete ordered set of signals.

If no signals were recorded (e.g., all markets were closed), the tree produces a deterministic empty root: SHA256("empty").

Step 2 — Persist to Postgres

The Merkle root, signal count, and full tree structure are saved to the attestations table. The record is idempotent — if an attestation already exists for that date, the run is skipped without error.

Step 3 — Submit to Base L2

The root is submitted to the SignalAttestation smart contract deployed on Base L2 via a single setRoot(dateKey, root) transaction:

• dateKey is a uint32 in YYYYMMDD format (e.g., 20260310)
• root is the 32-byte Merkle root as bytes32

The contract stores one root per date. Once written, it cannot be overwritten. The transaction hash is recorded back to Postgres.

Step 4 — Proof generation and verification

Given a signal_id and a date, the API reconstructs the Merkle inclusion proof — the list of sibling hashes needed to re-derive the root from that leaf. Any party holding the signal's five fields can:

1. Recompute the leaf hash locally
2. Walk the proof path to derive the root
3. Compare against the root stored on-chain

If the derived root matches the on-chain root, the signal's inclusion is proven. No trusted intermediary is required.

---

The contract interface

The SignalAttestation contract exposes three functions:

Function	Type	Description
setRoot(uint32 dateKey, bytes32 root)	write	Store the Merkle root for a date (owner only)
verifyRoot(uint32 dateKey, bytes32 root)	view	Check whether a root matches what's stored
roots(uint32 dateKey)	view	Read the stored root for any date

The contract is deployed on Base L2 mainnet. Contract address is available on request.

---

API endpoints

The metrics API exposes two endpoints for attestation data:

List attestation records

GET /attestations

Query parameters:

• date — filter to a specific date (YYYY-MM-DD)
• chain — filter by chain name (e.g. base)
• status — filter by status (confirmed, pending, failed)
• limit — max rows (default 50, max 200)

Example response:

{
  "attestations": [
    {
      "id": "...",
      "attestation_date": "2026-03-09",
      "merkle_root": "a3f8...",
      "tx_hash": "0xd4b1...",
      "block_number": 23184721,
      "chain": "base",
      "signal_count": 847,
      "status": "confirmed"
    }
  ],
  "total": 1
}

Verify a signal's inclusion

GET /attestations/{date}/verify/{signal_id}

Returns the Merkle proof for the specified signal on the specified date.

Example response:

{
  "signal_id": "550e8400-e29b-41d4-a716-446655440000",
  "date": "2026-03-09",
  "merkle_root": "a3f8...",
  "tx_hash": "0xd4b1...",
  "block_number": 23184721,
  "chain": "base",
  "contract_address": "0x...",
  "leaf_hash": "7c9e...",
  "proof": [
    { "sibling": "4d2a...", "direction": "right" },
    { "sibling": "8f1b...", "direction": "left" }
  ],
  "valid": true
}

The valid field confirms the proof re-derives to the stored Merkle root. A valid: true response means the signal is cryptographically proven to have existed in that day's session.

---

Verification without API access

For fully independent verification (e.g., by an auditor with no system access):

1. Obtain the signal's five fields: signal_id, timestamp, direction, confidence, symbol
2. Recompute the leaf: SHA256("{signal_id}|{timestamp}|{direction}|{confidence:.8f}|{symbol}")
3. Obtain the Merkle proof path from the API (or from a database export)
4. Walk the proof: for each step, hash (sibling, current) or (current, sibling) based on direction
5. Read the on-chain root via roots(dateKey) on the Base L2 contract
6. Compare the derived root to the on-chain root

No TRADEOS.tech credentials, VPN access, or trust required.

---

Operational notes

Schedule: Attestor runs at 00:05 UTC daily to ensure the previous day's data is fully written before the tree is built.

Idempotency: If the attestor is restarted mid-run, it checks for an existing record before building the tree. Duplicate attestations for the same date are not possible.

Dry-run mode: Setting CHAIN_SUBMIT_ENABLED=0 builds and stores the Merkle tree locally but skips on-chain submission. Used for testing and in environments without Base L2 connectivity.

Backfill: A specific date can be attested by setting ATTESTOR_TARGET_DATE=YYYY-MM-DD and running the service with ATTESTOR_RUN_ONCE=1.

Chain failure handling: If on-chain submission fails (RPC timeout, insufficient gas, etc.), the Merkle root and full tree are already persisted to Postgres. The submission can be retried via backfill without any data loss.

---

Relationship to the internal audit trail

On-chain attestation is complementary to, not a replacement for, the internal HMAC audit trail.

	Internal ledger	On-chain attestation
What it covers	Every event (intents, fills, risk events, agent actions)	Signal outcomes only
Tamper evidence	HMAC hash chain, continuously verified	Blockchain immutability
Verification requires	HMAC key (escrowed to auditor)	Public blockchain read
Granularity	Individual events	Daily Merkle root
Audience	Internal compliance, institutional auditors	Anyone

The internal ledger provides comprehensive coverage with regulatory-grade tamper evidence. On-chain attestation provides public, permissionless proof of signal activity — verifiable by anyone, anywhere, without a relationship with TRADEOS.tech.