# 4.4 Security and Privacy **Last updated:** October 30, 2025 At GRX Chain, protecting the network and safeguarding user assets is core to everything we do. Because public blockchains are transparent by design, we pair strong security controls with clear privacy guidance so participants can make informed choices. GRX Chain is owned and operated by **GRXCHAIN Inc. (BVI)**; GroveX exchange is operated by **GroveX Pty Ltd (AU)**. ### Network Security **Consensus & validator set (DPoS)** * Delegated Proof-of-Stake with an active validator set and on-chain governance. * Economic incentives and **slashing** discourage misbehaviour (e.g., double-signing, prolonged downtime). * While no system can guarantee immunity from coordinated attacks, DPoS and stake distribution aim to reduce the feasibility of Sybil/censorship attempts. **Cryptography** * Protocol components rely on well-vetted primitives to ensure transaction integrity and state immutability. * Keys that control funds never leave user custody. The protocol does not store or recover private keys. **Smart-contract safety** * Independent audits are strongly recommended for all core protocols and third-party dApps before mainnet deployment. * Best practices: thorough testing (unit/integration/fuzz), testnet staging, time-locked governance, minimal privileged roles, and **GRXscan** contract verification. **Operational security** * Hardened node configs, restricted RPC exposure, segmentation, monitoring/alerting, and documented incident playbooks. * Public endpoints are best-effort; for mission-critical workloads, run your own nodes or use a reputable provider with redundancy. **Continuous improvement** * We track emerging threats and iterate on validator policies, parameters, and tooling via governance. ### Threat Model & Assumptions * **Public, pseudonymous ledger:** On-chain data is transparent; privacy depends on user behaviour and off-chain disclosures. * **Non-custodial by default:** Users control keys. GRX Chain and GRXCHAIN Inc. never store or recover private keys. * **Economic security:** DPoS incentives + slashing; concentrated stake can increase certain risks. * **Third-party risk:** Bridges, wallets, RPC providers, oracles, indexers, and dApps have independent risk surfaces. ### Incident Response Policy (IRP) **Severities** * **SEV-1:** Chain halt/safety risk/consensus fault/widespread loss risk * **SEV-2:** Degraded performance, partial outage, validator misbehaviour spikes * **SEV-3:** Localised issues; minor endpoint incidents **Workflow**\ Triage → Contain → Communicate → Fix → Postmortem (publish within **7–14 days** for SEV-1/2). **Channels**\ Status updates on **status.grxchain.io**; summary in Docs **Changelog**. **Contact**\ **** (include impact, logs, hashes, contract addresses). ### Bug Bounty (Summary) * **Scope:** Core protocol, validator software, official portals (docs, explorer, RPC gateways), canonical contracts (incl. WGRX), and bridge integrations on **grovex.io**. * **Exclusions:** Social engineering, non-official domains, pure rate-limit findings without impact, self-XSS. * **Rewards:** Based on impact (funds at risk, chain safety, data exposure) and reproducibility. * **Rules:** Coordinated disclosure, no data destruction or privacy violations, legal safe-harbor as posted on the bounty page. ### Third-Party & Supply-Chain Security * **Audits & pentests:** Annual or on major releases for explorer, RPC gateways, and canonical contracts. * **Dependency hygiene:** Pin compiler/toolchain versions; verify bytecode for verified contracts; reproducible builds where possible. * **Keys & CI/CD:** Hardware-backed signing (HSM/YubiKey), SSO/MFA, least-privilege roles, mandatory code review, protected branches, signed releases. ### RPC & Endpoint Hardening * **Abuse controls:** Rate limits, per-IP quotas, request size caps, log-based anomaly detection. * **Isolation:** Public RPC nodes segmented from validator signing nodes; limited method exposure; TLS everywhere. * **Web security headers (portals):**\ `Content-Security-Policy: default-src 'self'`\ `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`\ `X-Content-Type-Options: nosniff` • `X-Frame-Options: DENY` • `Referrer-Policy: no-referrer` * **DDoS posture:** Anycast/CDN in front of public endpoints; autoscaling; circuit-breakers. ### Validator & Node-Operator Guidance * **Key management:** Signer separation; slashing-protection DB backups; offline key ceremonies for rotations. * **Networking:** Sentry architecture; firewall egress allow-lists; SSH via short-lived certs; no password logins. * **Observability:** Alerts on missed blocks, double-sign markers, latency, memory/disk thresholds, peer churn. * **Business continuity:** Multi-region snapshots; restore drills quarterly; documented failover runbooks. ### Smart-Contract Deployment Controls * **Change management:** Time-locked upgrades, multi-sig governance (published signers), emergency pause only if disclosed and time-bounded. * **Verification:** Mandatory **GRXscan** verification for canonical releases (exact compiler + constructor args). * **Runtime guards:** Minimise admin powers; scoped roles; circuit breakers on critical flows; pausable only with on-chain transparency. ### Phishing & Brand Protection * **Canonical domains:** `grxchain.io`, `grxscan.io`, `rpc.grxchain.io`, `grovex.io`. * **Email security:** Enforce SPF, DKIM, and DMARC (**p=reject**); publish `/.well-known/security.txt` with contact and policy. * **User guidance:** Never share seed phrases; support will never request keys or remote access. ### Privacy on GRX Chain **Public by design** * Transaction data (amounts, timestamps, addresses, contract calls) is visible on-chain and via **GRXscan**. * Activity is **pseudonymous**: addresses aren’t real-world identities unless linked off-chain. **User control** * You control your wallets and keys. GRX Chain does not store, recover, or access private keys. * Prefer hardware wallets (Ledger/Trezor) and verify recipients on-device. **Off-chain data & dApps** * dApps/services may process off-chain personal data (e.g., GroveX KYC, analytics, support). They should disclose practices and comply with applicable laws (e.g., GDPR principles where relevant). * Review each dApp’s privacy policy and requested permissions before connecting your wallet. **Future privacy enhancements** * We are exploring privacy-enhancing technologies (e.g., zero-knowledge proofs, selective disclosure) subject to governance and public documentation. ### Privacy Addendum (Off-Chain) * **Lawful basis:** Where personal data is processed, bases may include contract, legal obligation, or legitimate interests. * **Data minimisation & retention:** Collect only what’s necessary; define retention schedules; anonymise where feasible. * **Cross-border transfers:** Use SCCs or equivalent safeguards for international transfers. * **Data subject rights:** Access/rectification/erasure/objection handled via **** (subject to AML/record-keeping obligations). * **Cookies/analytics (web):** Provide a consent banner, granular toggles, and a public cookie list (strictly necessary vs optional). ### MEV & Fairness (Optional) * **Policy:** If MEV is present, we encourage transparent ordering, discourage harmful sandwiching/front-running on official infra, and will explore order-flow protections. * **Developer patterns:** Consider commit-reveal, frequent batch auctions, and other anti-MEV patterns for user-sensitive flows. ### Compliance Notes * Some services in the ecosystem (e.g., **grovex.io** bridging) may require **KYC** and are jurisdiction-dependent. * Participation in GroveX exchange services requires **18+** (see ToS). * Documentation is informational only and not financial or legal advice. ### Responsible Disclosure * **Report vulnerabilities:** **** with repro steps, impact, and affected contracts/tx hashes. * **Acknowledgement targets:** response within **2 business days**; status updates within **7 days**. * **Incidents:** track via **status.grxchain.io**; major events summarised in the Docs **Changelog**. ### Practical Privacy & Security Tips * Create purpose-scoped addresses for different activities (trading, identity, testing). * In UIs, show shortened checksummed addresses and link to **GRXscan**. * Minimise data collection in apps; prefer on-device storage; encrypt in transit and at rest; define clear retention periods. ### Quick Links * **Explorer:** * **Status:** * **Official bridge:** (current) * **Security reports:** * **Developer resources:** see **Developer Resources & Network Details** for network settings and canonical contracts. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.grxchain.io/4.4-security-and-privacy.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.