Skip to content
Epher Compute Chain epher.cc · by GINF Systems

Product · Epher Compute Chain

A small surface.
A large guarantee.

Two HTTP surfaces — one to write a ledger entry, one to dispatch a Borz contract — plus a tier knob and a published root public key. That is the entire product surface. Underneath: BLAKE3 chains, Ed25519 + Falcon signing, HATP attestation, Merkle checkpoints, proof-only public-chain anchoring, and a deterministic runtime that commits every call to a ledger.

Two pillars, one substrate

Storage and compute — equally first-class.

Every Epher Compute Chain deployment ships both pillars on the same hardware-attested mesh. You can use either pillar alone — many compliance buyers start with storage — or compose them, with Borz contracts whose inputs and outputs are themselves ledger entries.

Pillar I · Storage T0 → T4

Attested micro-ledgers.

Tamper-evident, append-only state with tier-parametrised retention. Pick a horizon from seconds to eternal and promote a ledger between tiers with a single call. Personal data stays off-ledger; only commitments are chained.

  • BLAKE3 content addressing, hash-chained, per-entry signed.
  • Ed25519 for the hot tiers; Falcon-1024 PQC for T3 and T4.
  • Merkle checkpoints, O(log N) inclusion proofs.
  • OpenTimestamps · L2 · EBSI anchoring (per ledger).
  • Per-record crypto-shred for GDPR Article 17.
Pillar II · Compute Borz · deterministic

Verifiable workflows.

Deterministic contracts written in Borz, running on a hardware-attested EU mesh. The runtime forbids non-determinism by interface; every call's inputs, code revision, state, and outputs are committed to a ledger entry. Replay reproduces the result byte-for-byte.

  • No wall-clock, no ambient I/O, seeded randomness.
  • Per-call accounting: bytes-in, bytes-out, ops counted.
  • Code revision committed; replays bind to the exact build.
  • State lives as ledger entries — no separate database.
  • Air-gappable on Epher Enterprise and Sovereign editions.

Capabilities

What you get when you provision a tenant.

01

Per-entry signatures

Every write is signed inside a hardware-attested KVM enclave bound to your tenant via the HATP key hierarchy. Offline-verifiable against a small published root key.

02

Hash-chained entries

Each entry references the BLAKE3 hash of its predecessor. Any modification of a past entry invalidates the chain forward — visibly, deterministically.

03

Tier-parametrised retention

Choose T0 through T4 per ledger; promote a ledger from session to compliance with a single API call. The wire format does not change.

04

Merkle checkpoints

Periodic roots produce O(log N) inclusion + consistency proofs. Anchored to Bitcoin via OpenTimestamps (default), or an L2 / EBSI per ledger policy.

05

Per-record crypto-shred

Personal data stays off-ledger; only commitments are chained. Right-to-erasure destroys the per-record key — the chain stays valid.

06

Post-quantum durability

T3 / T4 use Falcon-1024 (NIST PQC). Six-year retention without the harvest-now-decrypt-later exposure of Ed25519-only logs.

07

Deterministic contracts

Author workflows in Borz; deploy as Epher contracts. Every call is reproducible — the inputs, code, and outputs are themselves ledger entries.

08

Per-call EUR accounting

Each contract step records bytes-in, bytes-out, and deterministic-op count. Pricing is per-call in EUR on Epher Cloud; per-host on Enterprise.

09

Region pinning

Pin a ledger to a single EU region (eu-fra, eu-par, eu-ams, eu-bud, …) and it never replicates outside that region. Or replicate within EU for HA.

10

Strong consistency

Writes commit under per-ledger Raft consensus across the region. Reads after writes are monotonic; verification is exact.

11

Replay-ready exports

Download a self-contained, self-verifying export of any ledger or contract at any time. The verifier needs nothing from us.

12

Edition portability

Code written on Epher Cloud runs on Enterprise and Sovereign unchanged. The wire is the contract; the deployment shape is configuration.

API

The whole surface, in one screenful.

REST · Storage v1 · /ledger
# Create a ledger (tier is the only required policy)
POST /v1/ledger
{
  "id":    "orders",
  "tier":  "T2",
  "region": "eu-fra",
  "anchor": "ots:bitcoin"
}

# Append an entry (raw bytes; opaque to us)
POST /v1/ledger/orders/entry
Headers: Authorization, Idempotency-Key, X-Tier
Body:    application/octet-stream

# Read a range, optionally with inclusion proof
GET /v1/ledger/orders/range?from=1000&to=1042&proof=true

# Promote a ledger to a longer horizon
POST /v1/ledger/orders/promote
{ "to_tier": "T3" }

# Crypto-shred a single entry (right to erasure)
POST /v1/ledger/orders/entry/1042/shred

# Snapshot for offline verification
GET /v1/ledger/orders/export.cbor
REST · Compute v1 · /contract
# Deploy a Borz contract (code is hashed; the build is committed)
POST /v1/contract
{
  "id":        "loan_decision",
  "code_cid":  "b3:e019...4f72",
  "tier":      "T3",
  "region":    "eu-fra"
}

# Call a contract — deterministic; receipt is a ledger entry
POST /v1/contract/loan_decision/call
Headers: Authorization, Idempotency-Key
Body:    application/json | application/cbor

# Replay a prior call against the committed inputs + code
POST /v1/contract/loan_decision/replay/<step_receipt>

# List the contract's append-only call log
GET /v1/contract/loan_decision/log?from=0&to=99&proof=true

# Export the contract bundle (code + state + call log + proofs)
GET /v1/contract/loan_decision/export.cbor

Get started

Three steps, one afternoon.

  1. 01

    Create a project + key

    Email us — onboarding is white-glove during the early-access period. No credit card.

  2. 02

    Write your first entry — or deploy a contract

    Choose a tier, append a payload, get back a signed receipt. Or write a Borz contract and call it once to verify the receipt-replay loop.

  3. 03

    Verify, locally

    Run the open CLI against your export with our root public key. Nothing else required.

Request access

Tell us what you want to write to a ledger — or run as a contract.

We reply by hand. Average response time during early access: under one business day.