> For the complete documentation index, see [llms.txt](https://bitbook.rwatokens.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitbook.rwatokens.net/foundation/foundation/infrastructure-overview.md). # Infrastructure Overview ### Infrastructure Overview **Cloud Architecture · Security Posture · Development Pipeline · Operational Maturity** Public infrastructure documentation for institutional evaluators, auditors, prospective issuers across all three production modules (Equities, Real Estate, CORECM), and developers. This page describes the architecture, security practices, and operational environment that support the RWA Tokens platform — without exposing operational details that would aid adversaries. The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The issuer-onboarding and qualified-custody anchor is Empire Stock Transfer. > **Security Note:** This document intentionally omits IP addresses, hostnames, internal network topology, port configurations, and service-to-host mappings. Detailed infrastructure documentation is maintained internally and available to auditors under non-disclosure agreement. *** #### Table of Contents 1. ​Infrastructure Philosophy 2. ​Cloud Architecture​ 3. ​Environment Separation​ 4. ​Production Environment​ 5. ​Development Environment​ 6. ​CI/CD Pipeline​ 7. ​Network Security​ 8. ​Data Security​ 9. ​Monitoring and Alerting​ 10. ​Backup and Disaster Recovery​ 11. ​Blockchain Infrastructure​ 12. ​Object Storage​ 13. ​Module-Specific Infrastructure Considerations​ 14. ​Compliance Posture​ 15. ​Infrastructure Roadmap *** #### 1. Infrastructure Philosophy The platform's infrastructure follows three principles: **Environment isolation.** Development and production run on physically separate infrastructure with no shared credentials, no shared databases, and no network connectivity between them. A compromised development environment cannot reach production. **Defense in depth.** No single control protects any asset. Every production service is behind multiple independent security layers — network firewall, application authentication, TLS encryption, access logging, and runtime monitoring. Compromise of any single layer does not grant access. **Minimal attack surface.** Only the services required for production operation are exposed to the public internet. Internal services communicate over private networks. Administrative access requires key-based authentication — password authentication is disabled everywhere. These principles apply identically across all three modules. A real-estate issuance under Module 2 traverses the same hardened infrastructure as an equity issuance under Module 1 or a basin-asset issuance under Module 3. *** #### 2. Cloud Architecture **Provider** AttributeDetail **Primary provider** DigitalOcean **Compute** DigitalOcean Droplets (dedicated CPU available) **Object storage** DigitalOcean Spaces (S3-compatible) **Regions** US East and US West (multi-region) **Blockchain RPC** Helius (dedicated cluster) plus Triton (failover) — not self-hosted **DNS and CDN** Cloudflare (DDoS protection, CDN caching, SSL termination) **Monitoring** Datadog (metrics, logs, APM) plus PagerDuty (alerting) **Secrets** Encrypted environment configuration — not stored in source control **Architecture Diagram** Copy ``` INTERNET │ ┌──────▼──────┐ │ Cloudflare │ DDoS protection · WAF · SSL │ CDN + WAF │ Rate limiting · Bot mitigation └──────┬──────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌─────▼─────┐ ┌────▼────┐ ┌──────▼──────┐ │ Frontend │ │ CEDEX │ │ Issuer │ │ (Web App) │ │ API │ │ Portal │ └─────┬─────┘ └────┬────┘ └──────┬──────┘ │ │ │ ┌─────▼─────────────▼─────────────▼─────┐ │ PRIVATE NETWORK │ │ ┌──────────┐ ┌───────────────────┐ │ │ │ Backend │ │ Oracle Relay │ │ │ │ Services │ │ Services │ │ │ └──────────┘ └───────────────────┘ │ │ ┌──────────┐ ┌───────────────────┐ │ │ │ Database │ │ AI / IDOS │ │ │ │ Layer │ │ Module │ │ │ └──────────┘ └───────────────────┘ │ └──────────────────┬────────────────────┘ │ ┌────────────┼────────────┐ │ │ │ ┌─────▼─────┐ ┌───▼───┐ ┌─────▼─────┐ │ Helius │ │ Pyth │ │ Empire │ │ RPC │ │ Oracle│ │ Stock │ │ (Solana) │ │ │ │ Transfer │ └───────────┘ └───────┘ └───────────┘ EXTERNAL SERVICES (not self-hosted) ``` *** #### 3. Environment Separation PropertyProductionDevelopment **Purpose** Live CEDEX trading, oracle relays, investor-facing services Feature development, testing, staging **Isolation** Physically separate infrastructure No access to production data or credentials **Shared resources** None None **Credential overlap** Zero — no shared keys, tokens, or API credentials Zero **Network connectivity** Not connected to dev Not connected to prod **Deployment** Manual promotion with approval gates CI/CD automated **Access** Restricted to authorized operations personnel Available to engineering team **Data** Real investor and issuer data (encrypted) Synthetic / test data only *** #### 4. Production Environment **Compute** Service CategoryInstancesSpecificationsPurpose **Frontend** 1 Lightweight rwatokens.net and cedex.market web applications **Backend API** 1 Standard CEDEX REST API, WebSocket, order management **Oracle relays** Colocated with backend Standard Custody, OFAC, AML, TWAP, NAV (Module 2), federal-classification (Module 3), EDGAR relay services **Production Hardening** ControlImplementation **SSH access** Key-based only — password authentication disabled **Root login** Disabled — sudo via named user accounts **Firewall** DigitalOcean Cloud Firewall — default deny inbound, explicit allow per service port **Exposed ports** Minimum required (HTTPS 443). All other ports firewalled. **OS updates** Automated security patches (unattended-upgrades) **TLS** TLS 1.2+ enforced on all public endpoints. HSTS enabled. **DDoS protection** Cloudflare proxy — production IPs not publicly exposed **Rate limiting** Application-level (CEDEX API tiers) plus Cloudflare WAF rules **Logging** All access logs shipped to Datadog. Retention: 30 days hot, 1 year cold. **Intrusion detection** Automated alerting on SSH login, sudo usage, and failed authentication attempts **Uptime Target** ServiceTargetMonitoring CEDEX API 99.9% Datadog synthetic checks plus uptime monitoring Oracle relays 99.95% (custody relay critical) Datadog custom metrics plus PagerDuty escalation Frontend 99.9% Cloudflare analytics plus Datadog *** #### 5. Development Environment **Services** ServicePurpose **GitLab (self-hosted)** Source control, issue tracking, CI/CD pipelines, code review **Development backends** CEDEX API dev, oracle relay dev, integration testing **Design and project management** Penpot (open-source design), Plane (project tracking) **AI / IDOS development** EDGAR NLP pipeline, IDOS model training, wallet profiling **IPFS node** Decentralized content storage for on-chain metadata references **CDN development** CDN origin testing and static asset staging **Development Specifications** ResourceAllocation **Total compute** 6 development droplets across US East and US West **Total RAM** 45 GB aggregate development capacity **Total disk** 465 GB aggregate development storage **Largest instance** 16 GB RAM / 80 GB disk (AI module training plus project-management backends) **Development Tools** ToolPurposeHosting **GitLab CE** Source control, CI/CD, container registry Self-hosted (dedicated droplet) **Penpot** Open-source design tool (UI/UX) Self-hosted **Plane** Open-source project management Self-hosted **IPFS** Decentralized storage for metadata Self-hosted node **Docker** Containerization for all services On each droplet *** #### 6. CI/CD Pipeline **Pipeline Architecture** Copy ``` DEVELOPER │ ├─ git push → GitLab (self-hosted) │ ├─ GitLab CI triggers: │ ├─ Lint (cargo fmt + clippy + prettier + eslint) │ ├─ Unit tests (cargo test --workspace) │ ├─ Integration tests (anchor test) │ ├─ Security scan (cargo audit + npm audit) │ └─ Build artifacts (anchor build + docker build) │ ├─ Merge to develop → auto-deploy to dev environment │ ├─ Merge to main → requires: │ ├─ 2 code review approvals │ ├─ All CI gates pass │ ├─ No critical/high security findings │ └─ CTO sign-off (for smart contract changes) │ └─ Production deployment → manual promotion with checklist ``` **CI/CD Security** ControlImplementation **Secrets in CI** GitLab CI/CD variables — masked and protected. Never in source code. **Container scanning** Automated vulnerability scanning on Docker images **Dependency audit** `cargo audit` (Rust) plus `npm audit` (Node.js) on every pipeline run **Branch protection** `main` and `develop` branches protected — no force push, no direct commit **Artifact signing** Build artifacts include SHA-256 hash for reproducibility verification *** #### 7. Network Security **Defense Layers** Copy ``` LAYER 1: Cloudflare (edge) ├─ DDoS mitigation (L3/L4/L7) ├─ Web Application Firewall (WAF) ├─ Bot management ├─ Rate limiting ├─ SSL/TLS termination └─ Origin IP masking — production IPs not publicly resolvable LAYER 2: DigitalOcean Cloud Firewall ├─ Default deny inbound ├─ Explicit allow rules per service ├─ SSH restricted to authorized IPs └─ Inter-droplet communication via private network only LAYER 3: Application layer ├─ Wallet signature authentication (CEDEX API) ├─ Empire Stock Transfer verification gate ├─ API rate limiting per tier └─ Request validation and input sanitization LAYER 4: Runtime monitoring ├─ Datadog APM (application performance) ├─ Anomaly detection on all endpoints ├─ Failed authentication alerting └─ PagerDuty escalation (P0–P3) ``` **Network Isolation** Network SegmentVisibilityCommunication **Public-facing** (frontend, API) Internet via Cloudflare Inbound HTTPS only **Private services** (backend, oracles, DB) Private network only Not internet-accessible **Development** Separate infrastructure entirely No production connectivity **External APIs** (Helius, Empire, Chainalysis, TRM Labs) Outbound only Authenticated API calls over TLS *** #### 8. Data Security **Encryption** Data StateEncryptionStandard **In transit** TLS 1.2+ on all connections HTTPS enforced, HSTS headers **At rest (disk)** DigitalOcean volume encryption AES-256 **At rest (database)** Application-level encryption for PII AES-256 **At rest (object storage)** DigitalOcean Spaces server-side encryption AES-256 **Backups** Encrypted snapshots DigitalOcean managed **Sensitive Data Handling** Data CategoryStorageAccessRetention **Investor PII** Empire Stock Transfer (not platform-side) Empire only Per BSA (5 years) **KYC / KYB documents** Empire Stock Transfer Empire only Per BSA (5 years) **Transaction records** On-chain (immutable) plus compliance database Authorized compliance personnel 7 years (Securities Act) **Oracle attestations** On-chain (immutable) Public (Solana ledger) Permanent **API credentials** Encrypted environment variables Operations team only Rotated per schedule **Multi-signature keys** Ledger Enterprise HSM (not on servers) Key holders only Rotated annually **Module 2 appraisal records** Independent appraiser plus compliance database Authorized compliance personnel 7 years **Module 3 federal-classification records** Compliance database with USGS / DOE source attribution Authorized compliance personnel Permanent (federal record-keeping standard) **Access Control** ResourceAuthenticationAuthorization **Server SSH** Ed25519 key-based only Named user accounts, sudo logging **GitLab** SSO plus 2FA enforced Role-based (developer, maintainer, admin) **CEDEX API (public)** Wallet signature Empire-verified investors only **CEDEX API (admin)** Key-based plus IP whitelist Operations team only **Datadog / PagerDuty** SSO plus 2FA Role-based **DigitalOcean console** SSO plus 2FA CTO plus DevOps lead only *** #### 9. Monitoring and Alerting **Monitoring Stack** ToolPurposeCoverage **Datadog** Infrastructure metrics, application logs, APM traces All production services **PagerDuty** Alert routing and on-call management P0–P3 escalation policies **Cloudflare Analytics** Edge traffic, DDoS events, WAF blocks All public endpoints **DigitalOcean Monitoring** Droplet CPU, memory, disk, network All droplets **Custom health endpoints** Per-service health checks Oracle relays, CEDEX API **Key Dashboards** DashboardMetrics **CEDEX Trading** Order volume, fill rate, latency (p50/p95/p99), error rate — segmented by module **Oracle Health** Custody freshness (slot age), OFAC staleness, AML cache hit rate, NAV reappraisal cycle status (Module 2), federal-classification freshness (Module 3) **Transfer Hook** Control pass/fail distribution, error code frequency, latency **Infrastructure** CPU, memory, disk, network per droplet. RPC latency. **Security** Failed SSH attempts, failed API authentication, WAF blocks, rate-limit triggers **Alert Thresholds** AlertConditionSeverityResponse Custody oracle stale Slot age > 5 P0 Immediate — all transfers halt CEDEX API 5xx > 10% 5-minute window P1 1-hour response RPC failover triggered Primary Helius unreachable P2 4-hour response Disk usage > 85% Any production droplet P3 24-hour response Failed SSH login Any production server P2 4-hour review NAV oracle stale (Module 2) Reappraisal feed delayed beyond defined cadence P1 1-hour response — affected mints paused Federal-classification stale (Module 3) USGS / DOE classification feed unreachable beyond cache window P2 4-hour response — enhanced review on new transfers *** #### 10. Backup and Disaster Recovery **Backup Strategy** AssetMethodFrequencyRetentionTested **Production droplets** DigitalOcean snapshots Weekly 4 weeks Quarterly restore test **Databases** Automated managed backups Daily 30 days Monthly restore test **GitLab** Full backup (repos plus CI config plus issues) Daily 30 days Monthly restore test **Object storage** DigitalOcean Spaces versioning Continuous 90 days Quarterly **On-chain state** Solana ledger (immutable) N/A — permanent Permanent N/A **Configuration** Infrastructure-as-code in GitLab Every change Git history Every deployment **Disaster Recovery Targets** MetricTargetNotes **RPO (Recovery Point Objective)** 24 hours (worst case) Most data is on-chain (permanent). Off-chain data: daily backup. **RTO (Recovery Time Objective)** 4 hours New droplet from snapshot plus restore config plus verify services **On-chain data** Zero data loss — permanent Solana ledger is the authoritative record **Recovery Procedures** ScenarioProcedureRTO Single droplet failure Restore from latest snapshot to new droplet 1–2 hours Database corruption Restore from managed backup plus replay from on-chain state 2–4 hours Region failure Redeploy to alternate region from snapshots plus IaC 4–8 hours Complete provider failure Redeploy to alternate provider from GitLab backups plus IaC 8–24 hours On-chain programs Programs are deployed on Solana — independent of platform infrastructure 0 (already available) *** #### 11. Blockchain Infrastructure **Solana Connectivity** ComponentProviderSelf-Hosted?Purpose **Primary RPC** Helius (dedicated cluster) No — managed All Solana reads, transaction submission **Failover RPC** Triton No — managed Automatic failover on Helius outage **WebSocket** Helius enhanced No — managed Real-time slot/block subscriptions **MEV protection** Jito Block Engine No — managed Private transaction submission **Why RPC Is Not Self-Hosted** Running a Solana full node requires 512 GB RAM, 2 TB NVMe, and enterprise-grade networking — a $2,000+ per month dedicated server commitment. Helius dedicated clusters provide equivalent performance with 99.9% SLA, geographic redundancy, and enhanced WebSocket support at a fraction of the operational burden. The Triton failover ensures no single-provider dependency. **Oracle Relay Architecture** Oracle relay services run on platform infrastructure, bridging external data sources to on-chain oracle accounts. The relay set includes module-specific feeds for Module 2 (NAV) and Module 3 (federal classification): Relay ServiceExternal SourceUpdate CadenceOn-Chain TargetModule Scope Custody relay Empire Stock Transfer API Every block (\~400ms) CustodyOracle PDA All modules OFAC indexer U.S. Treasury OFAC API Hourly plus emergency push OFACOracle PDA All modules AML bridge Chainalysis KYT plus TRM Labs Per-transfer (cached 6h) AMLOracle PDA All modules TWAP consumer Pyth Network (on-chain) Continuous SecurityConfig TWAP All modules NAV relay Independent licensed appraisers Reappraisal-cycle cadence NAVOracle PDA Module 2 (Real Estate) Federal-classification relay USGS Critical Minerals List, DOE Critical Materials Strategy Daily plus emergency on EO update ClassificationOracle PDA Module 3 (CORECM) EDGAR pipeline SEC EDGAR RSS plus EFTS 60s poll plus daily batch IDOS state Module 1 (Equities) *** #### 12. Object Storage **DigitalOcean Spaces** PropertyConfiguration **Provider** DigitalOcean Spaces (S3-compatible) **Region** US West **Encryption** Server-side AES-256 **Access** Private by default — authenticated access only **CDN** DigitalOcean Spaces CDN enabled for static assets **Versioning** Enabled — 90-day retention **Storage Use Cases** Bucket CategoryContentAccess **Issuer communications** Issuer onboarding documents, communication records Authenticated platform personnel only **Static assets** Frontend assets, documentation files CDN (public) **Backup artifacts** Database dumps, configuration backups Encrypted, operations team only **Module 2 appraisal artifacts** Appraisal reports, supporting documentation Authorized compliance personnel only **Module 3 classification artifacts** USGS / DOE classification source records, geological surveys Authorized compliance personnel only > No investor PII, KYC documents, or financial records are stored in platform-managed object storage. All investor data is maintained exclusively by Empire Stock Transfer. *** #### 13. Module-Specific Infrastructure Considerations The same core infrastructure serves all three modules. Three module-specific extensions have measurable infrastructure implications: **13.1 Module 1 — Equities** **Infrastructure characteristics:** * Highest expected transaction volume of the three modules. * EDGAR pipeline integration for issuer-disclosure intelligence (Layer 9 IDOS). * Standard custody, OFAC, AML, and TWAP oracle dependencies. **Infrastructure-specific risks:** Transaction-volume spikes during issuer disclosure events (8-K, 10-Q, 10-K filings). Mitigated by Helius dedicated cluster headroom and Jito Block Engine bundling. **13.2 Module 2 — Real Estate** **Infrastructure characteristics:** * Lower transaction-volume cadence than Module 1, but higher per-transaction notional value. * Additional NAV oracle relay bridging independent licensed appraisers to on-chain pricing bands. * Per-property single-asset entity tracking in compliance database. **Infrastructure-specific risks:** Reappraisal-cycle gaps create on-chain pricing-band staleness. Mitigated by Module 2-specific monitoring of NAV oracle freshness with P1 alerting. **13.3 Module 3 — CORECM** **Infrastructure characteristics:** * Lowest expected transaction volume but highest regulatory sensitivity. * Federal-classification oracle relay sourced from USGS Critical Minerals List and DOE Critical Materials Strategy feeds. * Enhanced KYC depth in Empire onboarding pipeline for accredited basin-asset investors. **Infrastructure-specific risks:** Federal action under DPA Title III, Section 232, or Executive Order 14017 may require rapid Control 42 freeze coordination. Mitigated by federal-classification relay alerting plus established Empire-coordinated freeze procedure. **13.4 Cross-Module Infrastructure Properties** Identical across modules: * Network ingress and egress paths (Cloudflare → backend → Solana RPC). * Multi-signature authority for program upgrade and parameter adjustment. * Backup and disaster recovery procedures. * Datadog and PagerDuty alerting infrastructure. * Empire Stock Transfer custody and onboarding integration. *** #### 14. Compliance Posture **Infrastructure Compliance** RequirementImplementation **Data encryption at rest** AES-256 on all volumes and object storage **Data encryption in transit** TLS 1.2+ enforced on all connections **Access logging** All SSH, API, and admin actions logged to Datadog (30-day hot, 1-year cold) **Secrets management** Encrypted environment variables — not in source control, not on disk in plaintext **Patch management** Automated security updates (unattended-upgrades) **Backup verification** Monthly restore tests with documented results **Incident response** Documented runbooks (see Incident Response Playbook) with quarterly tabletop exercises **Change management** All infrastructure changes tracked in GitLab with approval workflows **SOC 2 alignment** Controls aligned with SOC 2 Type II trust service criteria (audit pending) **Separation of Duties** FunctionPersonnelOverlap **Smart contract deployment** CTO plus multi-signature holders No overlap with operations **Infrastructure operations** DevOps plus CTO No overlap with compliance **Investor data (KYC / KYB)** Empire Stock Transfer exclusively The platform has no access **Compliance decisions** Legal Counsel Independent of engineering **Key management** Designated multi-signature holders (Ledger Enterprise) Geographically distributed, no key overlap *** #### 15. Infrastructure Roadmap **Q3 2026 (Mainnet Launch)** InitiativeStatusPurpose Production hardening review In progress Pre-launch security audit of all production infrastructure Load testing at 600 TPS Planned Verify production capacity under mainnet trading load Disaster recovery drill Planned Full region-failover test before launch SOC 2 Type II audit Planned Institutional compliance requirement Module 2 NAV oracle production deployment Planned Required for Module 2 launch readiness Module 3 federal-classification oracle production deployment Planned Required for Module 3 launch readiness **Q4 2026 – Q1 2027** InitiativePurpose **Kubernetes migration** Container orchestration for auto-scaling, rolling deployments, and self-healing **Multi-region production** Active-active deployment across US East and US West for latency and redundancy **Dedicated database cluster** Managed PostgreSQL or MongoDB Atlas with read replicas and automated failover **Infrastructure-as-Code** Full Terraform / Pulumi coverage for reproducible deployments **WAF rule hardening** Custom Cloudflare WAF rules tuned to CEDEX API traffic patterns **2027+** InitiativePurpose **CDN edge compute** Cloudflare Workers for pre-flight compliance caching at the edge **HSM-backed API signing** Hardware security module for CEDEX API response signing **Zero-trust networking** Identity-verified access per request — no VPN dependency **Cross-region oracle relays** Geographically distributed relay services for oracle latency reduction *** #### For Auditors Detailed infrastructure documentation — including service-to-host mapping, network topology, firewall configurations, and credential management procedures — is available under non-disclosure agreement. Contact: PurposeContact Security audit / penetration test Infrastructure review (institutional) Compliance audit *** #### Related Documentation * **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations * **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis * **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces * **Network Configuration** — Program IDs, RPC endpoints, PDA registry, production parameters * **Incident Response Playbook** — P0–P3 runbooks, communication protocol * **Deployment Guide** — Build, deploy, verify procedures * **Oracle Integration Guide** — Relay service architecture, fail-safe cascade, module-specific oracles *** *RWA Tokens · Infrastructure Overview · Groovy Company, Inc.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://bitbook.rwatokens.net/foundation/foundation/infrastructure-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.