Skip to content

Attestation & Verifiable Compute

Every number SignalForge publishes — daily signals, intraday marks, and vault execution directives — carries a signed attestation envelope. There is no unsigned publication path. This page describes what those attestations claim, how they are verified, how daily signals are anchored on-chain, and how the whole system is governed.

Claims discipline

ACM is deliberate about what this system does and does not claim. It is an integrity system, not a confidentiality system — everything it protects is public. It is not described as "trustless" or "zero-knowledge", and input data is not claimed to be "cryptographically proven correct": input integrity is commitment-based, designed so that tampering is detectable and attributable rather than impossible. Zero-knowledge proofs of execution are an explicit non-goal at this stage.

The three claims

Each attestation supports three claims about the output it wraps:

  • C1 — Code integrity. The output was produced by a specific build of a specific code revision implementing a specific methodology version. In Phase 1 this is commitment-based (the build and revision identities are committed in the envelope); in Phase 2 it is backed by a TEE measurement checked against an on-chain registry.
  • C2 — Input integrity. The market data fed into the computation is committed per source, content-addressed, and persisted before signing. Deliberately detectable-and-attributable rather than impossible-to-fake.
  • C3 — Binding. The attestation is tied to this exact response — this index, this profile, this as-of date — and cannot be replayed against another.

The attestation envelope

Conceptually, every signal, mark, and directive carries:

attestation:
  code identity      build digest, code revision, configuration hash
  inputs hash        commitment to the content-addressed input bundle
  output hash        hash of the canonicalized response body
  binding fields     index, profile, as-of date, computation time
  key id + signature the publisher (or enclave) key and its signature

Three properties make the envelope independently checkable:

  • Canonicalization is standardized (RFC 8785 JSON Canonicalization Scheme), so any consumer can reproduce the exact bytes that were hashed and signed.
  • The output hash covers the response body minus the attestation block, so a consumer can recompute it directly from what it received.
  • Signatures are secp256k1 in an Ethereum-compatible scheme (EIP-191 personal-message, ecrecover-compatible), so verification works with commodity Ethereum tooling — including inside smart contracts.

A reference verifier and golden test fixtures are provided to integrating consumers.

Publication tiers and chaining

Tier Cadence Attested Anchored on-chain
Signal Daily — one canonical publication per index/profile per day; the same body and output hash all day Yes Yes (write-once)
Mark Intraday, on monitoring ticks of up to 30 seconds Yes No — chains to the day's signal via the signal's output hash
Directive Per request Yes No — carries attestation references (vault configuration hash, signal key and output hash, input-series hash) chaining it to the anchored daily signal

The chaining design means one on-chain write per index per day is enough to anchor everything: any mark or directive can be traced back to the anchored signal it derives from.

On-chain anchoring

Daily signal attestations are anchored on Arbitrum through a small set of purpose-built, security-audited Solidity contracts:

  • SignalAnchor — write-once daily anchors: for each index/profile series and date, the hash of the canonical attestation is recorded exactly once. Anchors are batch-written, and corrections are handled through an explicit supersede series — an anchor is never overwritten, so the original record of any correction survives.
  • KernelRegistry — the registry of approved compute identities and their signing keys per methodology version (the Phase 2 trust root). Consumers ask one question: is this key currently valid for this index and methodology version? Key revocation is terminal — a revoked key can never be re-approved, a property hardened during audit and enforced with invariant tests.
  • VaultSubscriptions — per-vault on-chain subscription records binding a vault to the index kernel, directive kernel, and vault configuration hash it has accepted. Vault governance must explicitly accept a subscription, and the contract offers a contract-grade check that a directive's keys are valid for that vault.

The contracts have been through a security audit; all findings were fixed with regression and invariant test coverage. Consistent with the audit's recommendation, an additional external audit is planned before the contracts are relied on for mainnet-critical flows. Publisher and contract identities are communicated to integrating consumers through the integration process.

How the platform verifies before execution

The execution platform treats verification as a precondition, not an afterthought. Before a signal or directive influences any transaction, the consumer:

  1. Recomputes the output hash over the canonicalized response body and checks it against the envelope.
  2. Recovers the signer from the signature and checks it against the expected key — a pinned publisher key in Phase 1, an on-chain registry validity check in Phase 2.
  3. Checks the binding fields — index, profile, as-of date — against what it asked for, defeating replay.
  4. Checks freshness against the published staleness windows in the strategy's risk-engine contract, and rejects any contract version it does not understand.

Only then does the platform act — and even a verified directive still passes through the platform's own policy allowlists and pre-flight simulation before signing (see Execution & Strategy Layer). Signal provenance and verification state are surfaced to partners in the portal alongside each vault's run history.

Deterministic, fail-closed production

Verifiability starts before signing:

  • Inputs are committed first. Each day's computation runs over a content-addressed input bundle — frozen, checksummed historical snapshots by reference, live data by value — persisted before any signature is produced. If the bundle cannot be persisted, publication is refused: the pipeline fails closed.
  • Compute is a pure function. Index computation is a deterministic function of the committed bundle, with determinism guarantees baked into the build (pinned dependencies, fixed hashing behaviour, single-architecture builds for floating-point reproducibility). A directive service can deterministically rebuild an index's level series from the committed bundle and reproduce the same hashes.
  • One canonical signal per day. Serving is read-through against the persisted attested record, so every consumer sees the same body and output hash all day — exactly what the on-chain anchor covers.

TEE execution — Phase 2

Phase 1 signs publications with a host-held publisher key that consumers pin out-of-band. Phase 2 — deployed in production — moves computation into trusted execution environments so that the code identity claim is machine-verified rather than pinned:

  • A kernel is one frozen pair of (index family, methodology version): calculator, configuration, frozen snapshots, and signer, packaged behind a minimal compute interface with no network egress.
  • Kernels run in Intel TDX-based confidential VMs. The deployed image is measured, and signing keys are derived inside the enclave, scoped to that exact measurement, and fail closed — a modified image simply cannot obtain the keys of the approved one.
  • The trust chain is anchored on two chains: key release is authorized on Base, and key validity is consumed on Arbitrum via the KernelRegistry — the same registry check consumers already use.

Kernel upgrades follow a two-path governance model:

  • Fast path — a non-semantic rebuild (dependency refresh, no methodology change) may re-register under the same version only if it reproduces a pinned golden corpus byte-for-byte, and even then only after a timelock.
  • Slow path — any semantic change is a new methodology version that every subscribing vault must explicitly accept.

The corollary is the never-fast-path rule: a fix for a genuine numerical bug always diverges on the golden corpus, so it is always a version bump — silent behavioural change is structurally impossible. Phase 2 is live in production, expanding kernel by kernel across the index family; indices not yet migrated continue to publish under Phase 1 publisher-key signing.

Governance and frozen artifacts

  • Methodology versioning. Every methodology document is versioned, and each strategy's risk-engine contract names its governing methodology. Published risk parameters change only with a methodology version bump.
  • Frozen product sets. A shipping product is frozen as a hash-committed artifact set: the methodology, a log of every divergence found and fixed during validation, a checksummed manifest, and (for vault products) the canonical tearsheet data and pinned index dependency. Frozen sets are measurements, not living documents: superseding one requires either a formal re-peg under the same version or a new sibling version — editing in place would break the hash pin and the attestation chain.
  • Jump-exposure attestations are mandatory. Every strategy wrapped with a jump-budget multiplier requires a signed jump-exposure attestation, and the HAVEN engine refuses to run without one — the requirement is enforced in code (see HAVEN).
  • Separated ownership roots. Control is split across three independently held roots: the publisher (registry and anchor administration), the enclave key-release owner, and per-vault governance. In an incident, registry-level revocation acts first — an instant kill switch for consumers — and enclave-key revocation is terminal.
  • Experiment governance. Research kill criteria are pre-registered before results exist, and killed experiments remain on the record (see the research workflow).

What a partner or auditor can independently verify

Without trusting ACM's word, an external party can:

  • Recompute the output hash of any signal, mark, or directive from its canonicalized body and confirm it matches the envelope.
  • Recover and validate the signer using standard Ethereum tooling, against the pinned publisher key or the on-chain registry.
  • Check the on-chain anchor for any index/profile and date and confirm it matches the attestation received — and confirm it was written once and never overwritten.
  • Trace a directive to its signal through the attestation references, and a mark to its signal through the signal's output hash.
  • Verify input commitments — confirm that the input bundle hash in the envelope matches the committed bundle, and that frozen snapshots match their checksums.
  • Verify frozen methodology sets against their published manifests, and confirm that a product's live parameters match its frozen, versioned contract.

Together these close the loop the overview describes: ACM produces signals under a controlled, versioned, attested process, and the platform — and anyone auditing it — can verify exactly what was published before it is executed under the platform's own risk controls.