1. Purpose of Security
The Enerdex Security Model requires conventional access controls, key management, operational monitoring, alongside source verification, authenticated participants, and validated ledger results. Security is a layered design requirement, not a guarantee established by architectural descriptions.
2. Hardware-Level Protections
- Trusted Execution Environments (TEE): Supported devices can attach source and firmware evidence. Hardware support and deployment must be independently verified.
- Nonce-Chain Continuity: Sequence checks help detect repeated or missing records; exceptions require investigation and recovery rules.
- Slope-Bounded Plausibility: Plausibility checks can flag anomalous measurements but cannot prove their physical accuracy.
These controls support evidence integrity while leaving hardware compromise and incorrect input as risks.
3. Consensus Mesh Security
- Verifier Mesh: The proposed quorum depends on authenticated membership, a selected protocol, and explicit fault assumptions.
- Signer Bitmap Density: Signer references must be verified against authorized membership and the applicable certificate policy.
- View Changes: Coordinator recovery needs to handle faults and uncertain submission outcomes without creating duplicate actions.
- Vote Latency Bounds: Network and processing anomalies need operational monitoring and realistic test coverage.
Application membership requires authorization controls separate from XRPL validator consensus.
4. XRPL Anchoring Security
- AnchorCommits: Proposed references link application evidence with supported XRPL transaction results.
- Application Validations: Check record identifiers, measurement sequence, authorization, and policy version.
- RecordLock Checks: Track accepted application records to help prevent duplicate submission.
- Rejection States: Failed or uncertain submissions require reconciliation with validated ledger results.
A validated transaction result confirms ledger execution, not energy delivery or source accuracy.
5. Cryptographic Envelope
- Hashing: Evidence digests require defined algorithms, canonical encoding, and implementation tests.
- Signatures: Signature choice must match device support, key lifecycle controls, and ledger compatibility. No post-quantum assurance is claimed.
- Aggregates: Verifier certificates require authenticated signer membership and a reviewed aggregation design.
- Merkleization: Merkle roots can commit to evidence but do not encrypt it or guarantee anonymity.
6. Threat Model & Mitigations
- Replay Attacks: Addressed through source identifiers, sequence controls, and durable duplicate detection.
- Duplicate Records: Application record locks and reconciliation help detect repeated processing.
- Epoch Regression: Sequence and measurement-window checks help identify inconsistent evidence.
- Mesh Partitioning: Requires availability testing, recovery procedures, and careful quorum assumptions.
- Anomaly Injection: Requires source checks, independent evidence, and review of anomalous measurements.
- Ledger Status: Reconcile against successful validated results; submission alone is insufficient.
7. Operational Review
Energy systems and application services need operational ownership, incident handling, and review of disputed evidence. Ledger finality does not remove those responsibilities. The proposed design requires implementation testing and independent security assessment. No completed audit or production security certification is asserted.
8. Interpretive Clause
Architecture material is not a security approval. It describes proposed evidence checks, verifier agreement, and ledger reconciliation.
Mechanisms such as signer bitmap density, epoch regression, or RecordLock checks require implementation review and testing before their protection can be relied upon.