Security Policy

1. Purpose of Security

The Enerdex Security Model is not rooted in firewalls, passwords, or conventional access control. Instead, it is enforced through physics-sealed proofs, Byzantine-resilient verifiers, and XRPL Hook determinism. Security is therefore not an overlay but a structural invariant, where violations collapse into immediate protocol-level rejection.

2. Hardware-Level Protections

  • Trusted Execution Environments (TEE): Each Storage Node (household, farm, cooperative) embeds an attestation key pinned to firmware. All watt-hour ticks are signed at source.
  • Nonce-Chain Continuity: Every proof is chained by a non-replayable nonce sequence. Any discontinuity voids the chain.
  • Slope-Bounded Plausibility: Prevents fabrication of non-physical discharge curves.

These measures ensure Enerdex Units cannot be synthesized ex nihilo; only real, attested surplus passes upstream.

3. Consensus Mesh Security

  • Verifier Mesh: Quorum formation requires ≥ 2f+1 threshold signatures. Forgery is mathematically impossible without collusion above fault tolerance.
  • Signer Bitmap Density: Each QC encodes validator participation; density gaps invalidate certification.
  • View Changes: Anchor Agent rotation occurs upon timeout or fault detection, preventing leader capture.
  • Vote Latency Bounds: Excess jitter or gossip skew is flagged as anomalous and excluded.

The Verifier Mesh itself is immune to Sybil assumptions because Enerdex UNL membership is cryptographically pinned, distinct from XRPL’s UNL.

4. XRPL Anchoring Security

  • AnchorCommits: Posted to XRPL with embedded Quorum Certificates.
  • Hook Validations: Enforce epoch monotonicity, ES uniqueness, and policy immutability.
  • MintLock Constraints: Guarantee one-time issuance of Enerdex Units per ES identifier.
  • Rejection States: Anchors violating uniqueness, duplication, or policy pin are immutably rejected at Hook level.

Thus, Enerdex cannot bypass XRPL determinism; ledger closure is the absolute arbiter.

5. Cryptographic Envelope

  • Hashing: SHA-256 across StorageProofs, ES IDs, QC digests.
  • Signatures: Hybrid model — Ed25519 for XRPL compatibility, optional lattice-based signatures for post-quantum survivability.
  • Aggregates: Quorum Certificates embed BLS-style multisignatures; impossible to decompose or counterfeit without quorum collusion.
  • Merkleization: All raw ticks collapse into irreversible Merkle roots; original samples are unrecoverable, ensuring privacy and authenticity simultaneously.

6. Threat Model & Mitigations

  • Replay Attacks: Prevented via nonce-chain and Hook ESSeen set.
  • Double-Minting: Blocked by MintLock + ledger rejection on duplication.
  • Epoch Regression: Rejected by Hook monotonicity enforcement.
  • Mesh Partitioning: Mitigated by view-change protocol and quorum wait.
  • Anomaly Injection: Plausibility checks at Storage Node and QC cross-validation.
  • Ledger Forks: XRPL finality ensures canonical state within ~3–5s.

7. No Human Intervention

Enerdex security is not discretionary. No administrator can override XRPL Hooks, relax quorum thresholds, or accept invalid proofs. Security enforcement is cryptographic, deterministic, and irreversible.

8. Interpretive Clause

By using Enerdex you accept that “security” does not mean intrusion detection, antivirus, or SOC monitoring. It means non-replayable proofs, non-fabricable QCs, and non-negotiable XRPL anchoring.

If you cannot parse terms such as signer bitmap density, epoch regression, or MintLock enforcement, you are advised not to rely on Enerdex outputs as security assurances.