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
Infrastructure Philosophy
Cloud Architecture
Environment Separation
Production Environment
Development Environment
CI/CD Pipeline
Network Security
Data Security
Monitoring and Alerting
Backup and Disaster Recovery
Blockchain Infrastructure
Object Storage
Module-Specific Infrastructure Considerations
Compliance Posture
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
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
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
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
security@rwatokens.net
Infrastructure review (institutional)
frank@rwatokens.net
Compliance audit
compliance@rwatokens.net
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.
Last updated
Was this helpful?