Protocol specification

Consensus

Enerdex Surplus-Storage Consensus. A framework for verifier agreement, deterministic anchoring, and energy provenance.

ESSC v1XRPL anchoredVerifier agreement
0% read

Purpose

Provide BFT agreement on how much dispatchable surplus is real before any on-ledger action occurs, then atomically anchor that agreement to the XRP Ledger (XRPL) for EDX issuance and settlement.

Actors & Keys

  • Storage Node (SN): Household/coop/farm with metered battery. Keys: SN_ed25519 (ledger), SN_device (TEE/firmware).

  • Verifier Node (VN): Enerdex validators that check claims. Keys: VN_ed25519. Maintains UNL-style allowlist (Enerdex UNL ≠ XRPL UNL).

  • Anchor Agent (AA): Rotating leader that posts quorum results to XRPL.

  • XRPL Hook (optional): On-account hook set to validate anchors/mint controls.

Time Model

Discrete epochs E of length Δ (e.g., 5–15 min). A claim pertains to a window [t0, t1] ⊂ E.

Data Structures

StorageProof (SP):

 
SP = {
  storage_id,               // fixed per battery inverter
  epoch_id = E,
 window = [t0,t1],
  kWh_avail,                 // measured surplus, dispatchable
  meter_root,                // Merkle root of raw meter ticks
  firmware_attest,           // TEE quote or signed firmware hash
  prev_nonce, nonce,         // anti-replay chain
  SN_sig = Sig_SN_device(H(SP))
}

EnergySlice (ES): indivisible claimable unit

 
ES = H(storage_id || E || t0 || t1 || nonce)

Vote & QuorumCertificate (QC):

 
Vote = Sig_VN(H(SP || ES || policy_params))
QC = { E, ES, SP_digest, S = AggSig(2f+1 Votes), vn_bitmap }

(Use Ed25519 multisig or BLS aggregate off-ledger; XRPL anchor stores S and vn_bitmap.)

AnchorCommit (AC):

 
AC = H(QC)

Posted to XRPL in a canonical transaction with memo/binary blob; Hook validates fields.

Protocol (Round per ES)

Phase 0 — Measurement (SN):

  1. Battery firmware emits ticks; TEE signs samples → meter_root.

  2. SN composes SP, chains nonce, signs with SN_device.

Phase 1 — Proposal (SN → VNs):
3. SN gossips SP to VNs in Enerdex mesh.

Phase 2 — Verification (VNs):
4. Each VN checks:

  • TEE/fabric signature validity & firmware allowlist.

  • Non-overlap: ES uniqueness (storage_id,E,nonce) not seen before.

  • Continuity: prev_nonce → nonce chain matches SN’s history.

  • Dispatchability: policy guards (SoC ≥ θ, grid/state flags OK).

  • Plausibility: Δ-bounded slope of ticks; no backfill; no time skew.

  1. If valid, VN issues Vote.

Phase 3 — Certification (AA):
6. AA collects ≥ 2f+1 Votes (Byzantine threshold for N VNs).
7. AA builds QC and AC = H(QC).

Phase 4 — XRPL Anchor (AA → XRPL):
8. AA posts Anchor Tx (e.g., AccountSet/Payment with memo blob) containing QC.

  • Optional Hook on EnerdexIssuer account validates:

    • epoch monotonicity,

    • ES uniqueness (seen set),

    • VN quorum (bitmap vs allowlist),

    • policy hash (frozen via Hook state).

  1. On XRPL ledger close, anchor achieves finality (~3–5s).

Phase 5 — EDX Mint & Lock (Issuer on XRPL):
10. Upon successful Hook check, EnerdexIssuer mints EDX (Issued Currency) equal to kWh_avail * R, where R is conversion rate.
11. A MintLock (state var/NFToken guard) binds EDX lot to ES to prevent re-mint.

Phase 6 — Trade & Settle (XRPL DEX):
12. Holder lists EDX via OfferCreate; trades clear on XRPL DEX.
13. Hook/daemon can burn-on-redeem or unlock-on-delivery as per market mode.

Safety & Liveness (Sketch)

  • Safety:

    • Non-overlap invariant: No two certified QCs share (storage_id,E,nonce); enforced by VN check + Hook set membership on XRPL.

    • One-mint per ES: MintLock + Hook rejection if ES seen.

    • Byzantine tolerance: With N VNs, tolerate f faulty if 2f+1 quorum used.

  • Liveness:

    • Under partial synchrony, AA eventually gathers quorum.

    • XRPL ledger closes provide bounded anchor finality.

    • Leader (AA) rotates if timeout (view-change).

Double-Claim Resistance

  • Physical layer: TEE-signed ticks, bounded drift, SoC threshold.

  • Consensus layer: nonce chain, ES uniqueness, epoch windows.

  • Ledger layer: Hook-maintained Seen(ES) set and MintLock per ES.

Cryptography & Identifiers

  • Device attestation: vendor TEE (e.g., Ed25519 over measured boot hash).

  • VN votes: Ed25519 multisig or BLS aggregate (off-ledger), exposed as S.

  • All hashes: H = SHA-256 (XRPL-native).

  • IDs: storage_id = H(serial || grid_id || owner_key).

Hooks (XRPL) – Minimal State Machine

  • state.seen[ES] = 1 on first valid anchor.

  • state.last_epoch[storage_id] monotonic.

  • state.policy_hash pinned (prevents mid-epoch policy swaps).

  • Reject mint if seen[ES]==1 or epoch regresses.

Economic Envelope

  • R (kWh→EDX) set by policy oracle; posted each epoch; hash pinned in Hook.

  • Optional bond from SN (in XRP/EDX) slashed if fraud proven (challenge window with counter-SP).

  • VN reputation score (on-ledger scalar) weights quorum participation over time.

Interfaces (sketch)

SN → VN

 
POST /prove
 body: SP
 resp: ack | err

VN → AA

 
gossip: Vote(SP_digest, ES)

AA → XRPL

  • Submit Anchor Tx with QC blob in memo; Hook enforces validity.

Issuer → XRPL

  • Payment of EDX to SN upon Hook approval (mint), tag = ES.

Pseudocode (Core Round)

 
def certify_and_anchor(SP):
 assert verify_device_attest(SP)
    ES = H(SP.storage_id, SP.epoch_id, SP.window, SP.nonce)
 for vn in UNL:
        send(vn, SP)
    votes = collect_votes(ES, quorum=2*f+1, timeout=τ)
    QC = make_qc(SP, ES, votes)
    tx = xrpl_build_anchor_tx(QC)      # memo holds QC blob
    xrpl_submit(tx)                    # Hook validates; ledger closes
 if hook_accepted(tx):
        amount = SP.kWh_avail * R
        xrpl_mint_EDX(to=SP.storage_id_owner, amount, ref=ES)

Why This Works for Enerdex on XRPL

  • Enerdex reaches application-layer consensus (ESSC) on physics-constrained data (stored kWh) before invoking XRPL, eliminating garbage-in.

  • XRPL provides deterministic, low-latency finality and a native DEX, so once a QC is anchored, EDX issuance and settlement are on-ledger, immutable, and cheap.

  • The trio (TEE proofs + ESSC QC + XRPL Hook state) closes the loop on measurement → agreement → settlement.

Scalability, Determinism, and Ledger Coupling

The Enerdex Surplus-Storage Consensus (ESSC) architecture is explicitly designed to scale horizontally without compromising the deterministic guarantees provided by the XRP Ledger (XRPL). Unlike probabilistic-finality chains, XRPL’s deterministic close model ensures that once a Quorum Certificate (QC) is anchored, the result is immutable and globally agreed within ~3–5 seconds.

Enerdex’s application-layer consensus exists orthogonally to XRPL consensus:

  • ESSC determines truth about a physical claim.

  • XRPL consensus determines order and finality of the accepted truth.

This separation enables parallelism in measurement verification while serializing settlement at the ledger layer, allowing high-throughput trade of EnergySlices (ES) without saturating XRPL transaction bandwidth.

Threat Model and Adversarial Resistance

Physical Layer Attacks

  • Forged Energy Claims: Mitigated via Trusted Execution Environment (TEE) attestations, firmware allowlists, and meter root Merkle proofs.

  • Replay / Double-Sell: Blocked by nonce chaining, ES uniqueness, and Hook state checks.

Consensus Layer Attacks

  • Byzantine Verifiers: ESSC tolerates up to f malicious VNs in a network of N nodes, requiring 2f+1 honest votes to finalize a QC.

  • Leader Misbehavior: Anchor Agent rotation on timeout ensures no single VN can block anchoring indefinitely.

Ledger Layer Attacks

  • Invalid Anchor Injections: Hooks validate QC structure, bitmap, policy hash, and epoch monotonicity before minting EDX.

  • State Rollback: XRPL’s deterministic close prevents forks that could roll back anchored QCs.

EnergySlice Lifecycle

  1. Creation: SN measures surplus, creates SP, and derives ES ID.

  2. Verification: VNs cross-validate SP and vote.

  3. Certification: AA aggregates votes into QC.

  4. Anchoring: QC committed to XRPL via Anchor Transaction.

  5. Issuance: Hook mints EDX tokens bound to ES.

  6. Trading: EDX enters XRPL DEX liquidity pools.

  7. Redemption / Burn: Upon delivery or offset, Hook burns corresponding EDX lot and retires ES from circulation.

Formal Invariants

  • Non-overlap Invariant: ∀ ES, ∃! MintEvent(ES)

  • Monotonic Epoch Invariant: epoch(storage_id)_{n} < epoch(storage_id)_{n+1}

  • Policy Lock Invariant: policy_hash_epoch_n == policy_hash_epoch_commit

These invariants are enforced jointly by VN verification rules and Hook state machine constraints.

Performance Considerations

  • Verification Latency: Median VN verification < 500 ms for standard SP payloads.

  • Quorum Formation: Target < 2 seconds for 2f+1 vote aggregation.

  • Ledger Settlement: Anchoring + XRPL finality within 5 seconds.

  • Throughput: Designed for 1,000+ concurrent ES verifications per epoch across distributed VN clusters.

Cross-Layer Flow Summary

 
[Physical Layer]
  Energy Device → SP → ES ID
      ↓
[Consensus Layer]
  VNs → Votes → QC
      ↓
[Ledger Layer: XRPL]
  Anchor Tx → Hook → EDX Mint
      ↓
[Settlement & Market]
  XRPL DEX Trade → Redemption/Burn

End-to-End Enerdex→XRPL Workflow

 
[ENERDEX PHYSICAL LAYER]
  Household / Farm / Coop Battery
        |
        v
  Energy Meter + TEE (Trusted Execution Env)
        |
        +--> Generate StorageProof (SP)
              (meter_root, firmware_attest, nonce chain)
        |
        v
  Derive EnergySlice ID (ES)
        |
        v
----------------------------------------------
[ENERDEX CONSENSUS LAYER - ESSC]
  SP → Verifier Nodes (VN)
        |
        +--> Validation:
              - TEE Signature Check
              - Non-overlap (ES uniqueness)
              - Policy Compliance
              - Dispatchability Check
        |
        v
  Votes Aggregated → QuorumCertificate (QC)
        |
        v
  Anchor Agent → AnchorCommit (AC)
        |
        v
----------------------------------------------
[XRPL LEDGER LAYER]
  Anchor Transaction to EnerdexIssuer Account
        |
        +--> XRPL Hook Validation:
              - Epoch Monotonicity
              - VN Quorum Bitmap
              - Policy Hash Match
              - ES MintLock Check
        |
        v
  Mint Enerdex EDX Tokens (Issued Currency)
        |
        v
----------------------------------------------
[XRPL MARKET LAYER]
  EDX Listed on XRPL DEX
        |
        +--> Trade / Swap / AMM Pools
        |
        v
  Redemption → Burn EDX → Retire ES

XRPL Hook State Machine for Enerdex

 
[HOOK ENTRY - Anchor Tx Received]
        |
  Validate QC → Verify Quorum Bitmap → Check Policy Hash
        |
+-- [INVALID] --> Reject Tx
|
+-- [VALID] --> Continue
|
  IF ES in state.seen:
        Reject (Double-Mint Attempt)
  ELSE:
        state.seen[ES] = 1
        state.last_epoch[storage_id] = epoch
        Mint EDX = kWh_avail * R
        Bind MintLock to ES
        Return Success

Enerdex EnergySlice Lifecycle on XRPL

 
[1] Creation
  - Measurement & Proof Generation
  - ES ID Derived

[2] Consensus
  - Verified by Enerdex VNs
  - QC Formed

[3] Settlement
  - QC Anchored on XRPL
  - Hook Validates & Mints EDX

[4] Trading
  - EDX Listed on XRPL DEX
  - Market Price Discovery

[5] Redemption
  - Energy Delivered / Offset
  - Hook Burns EDX & Retires ES
Back to topEnerdex framework