Why this matters

Compute markets—especially GPU—still rely on a mix of trust, screenshots, and manual dispute resolution:

• No objective finality for results. A job “completed” doesn’t automatically mean it was computed correctly.

• Replay and double‑spend style failures. Without canonical uniqueness, the same intent/receipt can be reused.

• Trust does not scale. More participants means more contracts, more human review, more conflict.

• Payable vs non‑payable gets mixed. Technical reservations often drift into quasi‑money narratives, creating integration and legal friction.

In short: compute is purchased “on faith” (centralized providers) or through systems where safety depends on reputation and chat logs.

What we’re building

ENTRPY + AETHEL is a three-layer stack:

L1 — ENTRPY Core (Financial Truth)

The settlement layer responsible for:

• credit accounting and enforcement,

• canonical anti‑replay (unique intent keys),

• staking/slashing and dispute rails,

• commitments and evidence anchoring.

L2 — ENTRPY Orbit (Execution)

The deterministic execution layer for:

• WASM and GPU workloads,

• strict determinism constraints (no “it depends on the machine” behavior),

• result finalization via commitments (e.g., OutputHash),

• dispute windows, trust downgrade, and penalties.

L3 — AETHEL (Policy & Clean Boundaries)

The policy layer that introduces a critical separation:

• ReservationCert (non‑payable): a capacity/quota reservation certificate. It is a technical guarantee, not money.

• UndertakingToken (payable): a settlement/undertaking artifact issued by a partner issuer when (and only when) a payable instrument is required.

This prevents a common failure mode: technical reservations accidentally becoming “shadow money.”

The core principles

1) Anti‑replay as a foundation

Each operation uses a canonical uniqueness key.
Replays are detected and rejected, eliminating “repeat the same intent to get paid twice” class failures.

2) Evidence over promises

A completed job is not a screenshot. The system relies on:

• cryptographic commitments,

• watchers/committees (where configured),

• dispute procedures with objective penalties.

3) Payable ≠ non‑payable (AETHEL separation)

A ReservationCert is not a payment instrument and should not circulate as one.
If a payable obligation is needed, it is a separate object (UndertakingToken) with separate issuance, rules, and auditability.

How it works (two simple flows)

Flow A: “Buy compute → get a final result”

1. A user reserves credits/budget.

2. A job is submitted to Orbit.

3. Executors compute and publish commitments (e.g., OutputHash).

4. After finality, credits settle under protocol rules.

5. If challenged, a dispute window opens for evidence and penalties.

Flow B: “Reserve capacity + issue a payable undertaking (when required)”

1. AETHEL issues a ReservationCert (technical reservation).

2. If a payable artifact is needed, a partner issuer issues an UndertakingToken bound to the cert.

3. Merchants verify signatures and status.

4. Settlement occurs under the issuer’s policy and the protocol’s constraints.

Why this is credible (no magic)

We’re intentionally building on “boring, auditable engineering”:

• explicit invariants and measurable SLOs,

• strict isolation of entities (reservation ≠ payment),

• a concrete threat model with a test matrix,

• observability (metrics/events) and reproducible evidence flows.

The goal is a system you can audit, test, and integrate into enterprise environments.

Who this is for

• platforms selling/buying GPU compute that need finality and fraud resistance,

• enterprises that want an internal compute/job market without “handshake economics,”

• partner issuers/payment rails that require clear boundaries: technical reservations remain non‑payable.

What exists today and what’s next

Documented and specified:

• L1/L2/L3 architecture,

• invariants,

• threat model + test matrix,

• interfaces (messages/errors),

• evidence scenarios,

• operational runbook pieces.

Next milestones:

• devnet + pilot integrations,

• partner issuer integration for UndertakingToken,

• public benchmarks and demo runs,

• external review/audit of critical modules.

We’re looking for

Investors and partners to accelerate:

• implementation + testing,

• pilots with real GPU pools,

• issuer partnerships for payable undertakings,

• first production contracts.

Technical documentation

• HackMD spec (Overview + Appendices)

Contact

• X: @Aethel_L3

• Email: bulhenvaster@gmail.com

• Telegram: https://t.me/bulhenvaster