Security

Validator fleet (production voting path)

• Primary: Singapore — production voting validator, BAM-enabled Jito client, DoubleZero connectivity.
• Hot-swap failover: Dallas — standby configured for identity handoff without extended delinquency.
• Hard operating rule: software upgrades, restarts, and invasive maintenance on the primary always begin with hot-swap to the failover. Zero-downtime is non-negotiable.

Supporting infrastructure

• Dedicated RPC / data-plane capacity separate from the voting primary where architecture requires it.
• Governance and ecosystem RPC roles on isolated hosts (not the same failure domain as the voting primary).
• Testnet capacity used for client diversity and protocol readiness — isolated keys and identity from mainnet.

Host & network baseline

• Modern Ubuntu LTS fleet.
• SSH key-based admin access; no password SSH for operators.
• Firewall / exposure minimized to required service ports.
• Public marketing and app surfaces on separate platforms from the validator host OS.
• Secrets and API tokens stored in a password manager / secret store — not in application source, chat logs, or client bundles.

Standing rules (non-negotiable)

1. No private keys, seeds, or mnemonics in tickets, chat, git, screenshots, or frontend code.
2. No RPC provider API keys in client-side code. Browser bundles are public. Wallet and account reads on public app surfaces go through a server-side BFF (or equivalent proxy).
3. Rotate on suspected exposure. Partial exposure in a screenshot or log is enough to rotate.
4. Separate duties where practical: validator host keys ≠ portal billing keys ≠ monitoring SaaS tokens ≠ personal workstations.

What we do not do

• We do not ask stakers for seed phrases.
• We do not run custodial staking wallets for the public.
• We do not put withdrawal authorities in the RPC portal application.

Commercial RPC (customers)

Authenticated JSON-RPC uses a keyed model:

• Key ID in the request (api-key query parameter)
• Secret in the X-API-Key-Secret header
• Rate limiting at two independent layers: connection and abuse controls at the network edge, and per-key, per-tier request enforcement at the application policy layer. Exceeding your tier returns a standard JSON-RPC rate-limit error rather than silent degradation.
• The authentication path fails closed: requests that cannot be authenticated, or that hit defined upstream failure modes, are rejected rather than served unauthenticated.

Portal accounts support magic-link auth and wallet connect for account/billing surfaces. Transactional email is sent from Digital Energy–controlled mail infrastructure (mail.digital-energy.io).

First-party app path (our own /stake and related surfaces)

Browser → Backend-for-Frontend (BFF) → Digital Energy RPC using a server-side partner credential.

The browser must not hold production RPC secrets. After any related deploy, Network-tab verification should show no third-party RPC hosts with embedded api-key= material from the client.

Administrative access

• Operator access to infrastructure is individual and key-based.
• Vendor access (e.g. build partner) is scoped to the systems they operate (portal app, billing webhooks) — not validator withdrawal authorities.
• Live payment-platform keys for the portal are restricted keys scoped to required capabilities; full unrestricted secrets are not shared broadly.

Voting path

Digital Energy runs a primary / hot-spare model:

1. Primary produces votes in Singapore.
2. Dallas spare is kept catchup-ready for takeover.
3. Planned work uses scripted hot-swap procedures so the cluster sees continuity rather than an unprotected restart on the live primary.

Hot-swap is exercised routinely in production — at roughly biweekly cadence as part of normal maintenance — not merely documented. Failover procedures that are only tested during incidents are failover procedures that fail during incidents.

RPC HTTP path

Customer HTTP RPC is served by Digital Energy infrastructure. Managed upstream capacity from established infrastructure providers is held as failover coverage — used when the primary data plane is unavailable, so a single host outage does not have to equal total customer hard-down.

What that means for your data: during failover coverage, requests carry the same information any RPC endpoint receives — public addresses, signatures, and transactions the client chooses to submit. Upstream providers never receive customer account credentials, key secrets, or billing data.

Important honesty note: a successful response from the public RPC hostname means the edge answered — not always that the primary validator process is healthy. We monitor both the edge and the validator directly.

WebSocket failover and advanced health-gated routing are iterated as capacity and product tiers mature; status of those paths should be reflected in product docs as they ship — not overclaimed here.

What failover is for

• Kernel / client upgrades
• Host maintenance
• Disk / accounts DB operations
• Controlled incident isolation

Failover is not a substitute for key compromise response (see Incident response).

Edge controls

• Authenticated access for paid/keyed tiers; unauthenticated abuse gets cheap rejection at the edge.
• Method classification and policy enforcement for JSON-RPC.
• Per-tier rate limits enforced per key at the policy layer, with connection and flood controls at the edge — two layers, independently verified in production testing.
• Partner / first-party credentials short-circuit on a dedicated path so internal page loads are not subject to end-customer tier ceilings.
• TLS on public endpoints.
• Browser-vs-API distinction on marketing hostnames where configured (API stays API; humans get the landing experience).

Data handled at the RPC layer

RPC requests may include:

• Public Solana addresses and signatures the client chooses to query
• Signed transactions the client chooses to submit

RPC does not receive seed phrases. If a client pastes a secret into a wallet or form, that is outside this interface's design.

Logging

Operational logs retain request metadata needed for abuse response, billing attribution, and reliability (timestamps, auth subject, method class, upstream outcome). Logs are treated as sensitive operational data — not a public dataset.

Public web apps (app.digital-energy.io, portal, landing)

• Hosted on modern app platforms with HTTPS.
• Secrets belong in server environments and secret managers.
• Stake and wallet reads/sends that require RPC go through server-side mediation for first-party pages.
• Dependency and deploy access limited to authorized operators and the contracted build partner.

Supply chain / vendors

We use specialized vendors for:

• Application build and portal engineering (Digisol)
• Email delivery
• Payments (fiat rail + optional crypto checkout as productized)
• Node hosting / bandwidth providers
• Upstream RPC / data-plane capacity
• Monitoring and analytics

Vendors do not receive validator withdrawal authorities. Credentials issued to vendors are revocable.

Validator health

Automated checks run continuously against the production fleet, covering, among other signals:

• Process / service liveness
• Delinquency and vote health (checked against independent remote RPC, not only the node's own view)
• Slot lag and catchup state
• Private connectivity paths where used (e.g. DoubleZero tunnels)
• Client and system version drift

Alerts are delivered to the operator's on-call channel with stateful alert/recovery logic — one page per condition, a recovery notice on clear, not a flood. The alert path itself is periodically exercised end-to-end with real deliveries, not assumed.

A deeper interactive diagnostic covers host-level posture on demand: CPU isolation and IRQ pinning, clock sync, service states, log red-flag scans, and connectivity tunnels.

External third-party delinquency monitoring provides an independent watchdog on the mainnet voting identity — an alert path that does not depend on our own infrastructure being healthy.

RPC / product

• Edge and auth path health
• Failover indicators on the HTTP path
• Customer lifecycle signals (billing webhook delivery, transactional mail) operated with our build partner

Severity model (operator practice)

Compromise playbook (summary)

1. Contain — isolate affected host/credential; disable exposed keys.
2. Preserve voting — fail over if the primary is unsafe.
3. Rotate — validator-adjacent secrets, API keys, portal secrets, and vendor tokens as indicated.
4. Audit — access logs, deploy history, auth anomalies.
5. Communicate — stake program partners and affected RPC customers when material.
6. Remediate — root cause, monitoring gap, runbook update.
7. Review — update this page's "Last reviewed" when posture materially changes.

Customer RPC incidents

For authenticated API customers: status via portal/email channels and remediation of key abuse (revoke/reissue). We do not publish customer key material in tickets or public channels.

Continuity measures in place

• Hot-swap failover for voting continuity during maintenance and many incident classes — exercised routinely, not shelf-ware.
• Multisignature treasury — no single key can move funds, so a lost or compromised device is a recoverable event, not a terminal one.
• Documented operational procedures for upgrades, health checks, and recovery.
• A written continuity instrument (letter-of-instruction covering operational and financial succession) in active formalization with estate counsel engagement underway.
• Separated authorities so application outages do not equal stake-withdrawal compromise.
• Monitoring that pages the operator on production faults, plus independent third-party delinquency monitoring that does not depend on our own infrastructure.

Key-person (key-man) risk — honest disclosure

A single primary operator concentrates decision speed and context. Mitigations in place or in motion include:

• Written runbooks for routine and emergency host actions
• Failover capacity that does not require rewriting the network from scratch
• A formal succession and continuity instrument in active preparation, with trusted-peer continuity pairing under development — without placing withdrawal authorities in casual third-party hands
• Vendor retainers for application-layer recovery (portal/billing), separate from consensus keys

We do not claim a 24/7 multi-continent NOC. We claim accountable, practiced, monitored single-operator infrastructure with engineered failover — and we are deliberately closing the gap between "single operator" and "single point of failure."

Business continuity (BCP) summary

Also useful:

• Validator performance
• Public stake explorers (StakeWiz, Validators.app, Solana Beach, etc.)
• Public Evidence Index (gist)
• On-chain vote and identity accounts published on our site and validator info

SOC 2

SOC 2 audit process under evaluation.

We do not claim SOC 2 Type 1 or Type 2 certification. We do not publish a target audit quarter on this page.

Payments & customer data

• Fiat billing via established payment processors under their compliance programs.
• Customer account email and billing metadata handled for account operation only.
• Crypto checkout, when enabled, verifies settlement server-side against our own infrastructure controls before entitlement changes.

Regulatory note (staking)

Staking and validator operation are described here as infrastructure services. Nothing on this page is investment, legal, or tax advice.

Email: [email protected]

(Alias monitored by the operator.)

Please include:

• Affected URL / host / endpoint (no customer secrets)
• Description and impact
• Reproduction steps or proof-of-concept without destructive testing on mainnet stake or third-party funds
• Your contact for follow-up