1. Security Overview
FeedOracle is a data infrastructure platform. We aggregate, normalize, and sign public data from blockchain networks, central banks, and climate organizations. The security posture reflects this scope: we do not hold customer funds, process payments on behalf of users, or store sensitive personal data beyond API credentials.
Security Principles
- Minimal data surface. No PII required for API evaluation. API keys are the only credential stored.
- Cryptographic evidence. Every API response can be independently verified via ECDSA signatures and on-chain anchors.
- EU-based infrastructure. All primary systems hosted in Germany with encrypted backups within the EU.
- Defense in depth. TLS 1.2+ everywhere, Cloudflare DDoS protection, fail2ban, restrictive firewall rules, SSH key-only access.
Transport Security
| Layer | Implementation |
|---|
| TLS | 1.2 and 1.3, managed via Cloudflare |
| HSTS | Enabled with max-age=31536000; includeSubDomains |
| Certificate | Cloudflare-issued, auto-renewed |
| DDoS Protection | Cloudflare WAF + rate limiting |
Server Security
| Control | Implementation |
|---|
| SSH Access | Key-based only, password authentication disabled |
| Firewall | UFW with deny-by-default, explicit port allowlisting |
| Intrusion Prevention | fail2ban with aggressive ban thresholds |
| OS Updates | Unattended security updates enabled |
| Service Isolation | Dedicated systemd services with restricted permissions |
2. Key Management & Signatures
FeedOracle uses ECDSA (secp256k1) signatures to provide cryptographic proof of data delivery. This is the same curve used by Bitcoin and Ethereum, enabling independent verification by any client.
Signing Architecture
| Component | Details |
|---|
| Algorithm | ECDSA with secp256k1 curve (ES256K) |
| Key Format | PEM-encoded, file-system stored with restricted permissions (0600) |
| Signing Scope | API response body (JSON payload + timestamp + endpoint path) |
| Verification | JWKS (canonical): /.well-known/jwks.json · Alias: /jwks · PEM export: /.well-known/feedoracle-signing.pub |
Key Lifecycle
| Event | Policy |
|---|
| Key generation | Generated on-server using OpenSSL, never transmitted |
| Key rotation | Annual rotation target. Old keys remain valid for verification of historical signatures for 12 months after rotation. |
| Key compromise | Target: immediate revocation and re-signing of active evidence packs. Target: notification to enterprise customers within 24 hours. |
| Key storage | File-system, restricted to signing service user. Not stored in databases or version control. |
On-Chain Anchoring
Evidence hashes are anchored to public blockchains for tamper-proof timestamping:
| Chain | Purpose | Frequency | Verifiable At |
|---|
| XRPL | Primary anchor (memo field) | Per-report | XRPScan |
| XRP Ledger | Secondary anchor | Per-transaction | XRPScan |
3. Access Controls
API Authentication
| Method | Details |
|---|
| Authentication | API key via X-API-Key header or api_key query parameter |
| Key format | 64-character hex string, unique per account |
| Key provisioning | Automated via dashboard registration |
| Key revocation | Immediate via dashboard or support request |
| Rate limiting | Per-key, tiered by subscription plan |
Tiered Access
| Tier | Rate Limit | Endpoints |
|---|
| Free | 100 req/day | Core carbon + RWA (read-only) |
| Developer | 5,000 req/day | All public endpoints |
| Professional | 50,000 req/day | All endpoints + Evidence Packs |
| Enterprise | Custom | All endpoints + S3 exports + priority |
Administrative Access
| Scope | Control |
|---|
| Server access | SSH key-only, restricted to operations team |
| Database access | Local socket only, no remote connections |
| Deployment | Manual review required, no automated deployments to production |
| Third-party access | No third-party administrative access to production systems |
4. Availability & SLOs
Service Level Objectives
| Metric | Target | Measurement |
|---|
| API Availability | 99.5% monthly | Uptime monitor (1-min intervals) |
| Response Time (p95) | < 500ms | Uptime monitor |
| Data Freshness (on-chain) | ≤ 15 minutes | Per-endpoint internal metric |
| Data Freshness (scores) | ≤ 24 hours | Daily recalculation |
| On-Chain Anchoring | ≤ 24 hours | Verifiable on-chain |
Note: These are operational targets (SLOs), not contractual guarantees. Enterprise customers may negotiate custom SLAs with defined remedies. Contact
enterprise@feedoracle.io.
Incident Response
| Severity | Definition | Response Target | Update Frequency |
|---|
| P1 — Critical | Complete API outage | 30 minutes | Every 30 min |
| P2 — Major | Degraded performance or partial outage | 2 hours | Every 2 hours |
| P3 — Minor | Non-critical issue, single endpoint | 24 hours | Daily |
| P4 — Informational | Cosmetic or documentation issue | Best effort | On resolution |
Maintenance Policy
Planned maintenance is performed during low-traffic windows (typically 02:00–05:00 CET) and announced at least 48 hours in advance via the status page. Enterprise customers receive email notification.
5. Logging & Monitoring
| System | What Is Logged | Retention |
|---|
| API access logs | Endpoint, timestamp, response code, API key hash, latency | 90 days |
| Application logs | Service events, errors, data refresh cycles | 30 days |
| Security logs | SSH access, failed auth attempts, firewall events | 90 days |
| Anchor logs | On-chain transaction hashes, Merkle roots | Permanent (on-chain) |
Alerting
| Alert Type | Channel | Response |
|---|
| Service down | Telegram + uptime monitor | Target: immediate investigation |
| High error rate | Telegram alerts | Within 15 minutes |
| Stablecoin deviation (RLUSD) | Circuit breaker + Telegram | Automatic + manual review |
| Failed anchor | Telegram alerts | Next business day |
| Disk/resource threshold | Health check system | Hourly automated checks |
What is NOT logged: Request bodies, full API keys (only hashed), IP addresses in application logs (only in nginx access logs with standard retention).
6. Data Handling & Retention
Data Categories
| Category | Examples | Storage | Retention |
|---|
| Public blockchain data | TVL, transactions, holder counts | SQLite + ClickHouse | Indefinite |
| Public economic data | FRED rates, ECB data, World Bank | SQLite | Indefinite |
| Derived scores | Risk scores, CCI scores | SQLite | Indefinite (versioned) |
| Evidence artifacts | Signed evidence packs, Merkle proofs | File system + on-chain | Indefinite |
| API credentials | API keys, email addresses | JSON/SQLite (encrypted at rest) | Until account deletion |
| Access logs | Request metadata | Log files | 90 days |
Data Not Collected
- No customer financial data, account balances, or portfolio positions
- No government-issued identity documents
- No payment card information (payments via external processor)
- No behavioral tracking or profiling beyond minimal analytics
Backup Policy
| Component | Frequency | Method | Retention |
|---|
| Website & configuration | Daily (03:00 CET) | Compressed archive | 7 days rolling |
| RWA data & models | Daily | Compressed archive | 7 days rolling |
| Carbon monitoring data | Daily | Compressed archive | 7 days rolling |
| Off-site sync | Daily | rsync to EU backup server | 7 days rolling |
RPO/RTO targets: Recovery Point Objective: ≤ 24 hours. Recovery Time Objective: ≤ 4 hours for critical services.
7. Infrastructure & Data Residency
| Component | Location | Purpose |
|---|
| Primary API servers | Germany (netcup GmbH) | API processing, databases, signing |
| Gateway server | Germany (netcup GmbH) | Orchestration, monitoring, off-site backup |
| CDN / DDoS | Cloudflare (EU primary, global edge) | TLS termination, caching, protection |
| On-chain anchors | XRPL (active), Polygon (planned) | Tamper-proof timestamping |
Data Residency Statement
All customer data and derived data products are stored exclusively on EU-based infrastructure (Germany). Cloudflare may route requests through non-EU edge nodes for performance, but does not persistently store API response data. On-chain anchors contain only cryptographic hashes (SHA-256) and contain no personally identifiable or commercially sensitive information.
8a. Subprocessors (Data Processing)
The following third-party service providers process data on behalf of FeedOracle in the GDPR sense:
| Provider | Purpose | Data Processed | Region |
|---|
| netcup GmbH | Infrastructure hosting | All application data | Germany (EU) |
| Cloudflare, Inc. | CDN, DDoS protection, TLS termination | HTTP requests (transit only) | Global (EU primary) |
| ISRG (Let's Encrypt) | TLS certificates | Domain names (automated issuance) | US (automated) |
No customer data is shared with analytics, advertising, or AI training services. Subprocessor changes are documented in the changelog below. Enterprise customers can subscribe to change notifications via enterprise@feedoracle.io.
8b. External Data Sources
FeedOracle aggregates publicly available data from the following third-party sources. These are not subprocessors; no customer data is transmitted to them. FeedOracle consumes their published APIs or datasets.
| Source | Data Category | Integration |
|---|
| DeFiLlama | Protocol TVL, RWA category data | Public API |
| Federal Reserve FRED | T-Bill rates, CPI, economic indicators | Public API |
| ECB (European Central Bank) | Euro area rates, monetary policy data | Public API |
| World Bank | Country-level economic indicators | Public API |
| Ankr Multi-Chain RPC | On-chain data across 50+ networks | Public API |
| GeckoTerminal | DEX liquidity, trading pairs | Public API |
| CCRI | Blockchain energy and carbon ratings | Public API |
| EMBER Climate | Global electricity and emissions data | Public API |
| VeChain ToolChain | DNV-certified carbon lifecycle data | Public API |
| Climatiq | Emission factors | Commercial API |
| EU ETS | Carbon allowance pricing | Public data |
Full source documentation including update frequencies and methodology: Methodology & Sources.
8c. Anchoring Networks (Public Chains)
Evidence hashes are anchored to public, permissionless blockchains for tamper-proof timestamping. Only cryptographic hashes (SHA-256) are written on-chain. No customer data, PII, or commercially sensitive information is published.
| Network | Purpose | Data Written | Verifiable At |
|---|
| XRPL | Primary anchor (per-report) | SHA-256 hashes only | XRPScan |
| XRP Ledger | Secondary anchor | SHA-256 hashes only | XRPScan |
Public blockchains are decentralized networks, not service providers. FeedOracle has no contractual relationship with or control over these networks.
9. Vulnerability Disclosure
Reporting a Vulnerability
If you discover a security vulnerability in FeedOracle's systems, we ask that you report it responsibly.
| Field | Details |
|---|
| Contact | security@feedoracle.io |
| Encryption | PGP key available on request |
| Acknowledgment | Within 48 hours of receipt |
| Initial assessment | Within 5 business days |
| Resolution target | Critical: 72 hours. High: 14 days. Medium/Low: 30 days. |
Scope
In scope: feedoracle.io, api.feedoracle.io, analytics.feedoracle.io, and all API endpoints documented at /docs.html.
Out of scope: Third-party services (DeFiLlama, FRED, Ankr, etc.), social engineering attacks, denial of service testing.
Safe Harbor
We will not pursue legal action against researchers who report vulnerabilities in good faith, follow this disclosure process, and avoid accessing or modifying customer data.
10. Compliance Framework Mapping
FeedOracle maps operational practices to recognized frameworks. These mappings support vendor due diligence but are not certifications.
Honest note: FeedOracle is not yet ISO 27001 certified or SOC 2 attested. We have designed controls with reference to these frameworks and document our alignment transparently. If your procurement process requires formal certification, please contact us to discuss our roadmap and interim evidence packages.
11. Enterprise Procurement Pack
Pre-packaged documentation for vendor due diligence and procurement workflows:
| Document | Contents | Format |
|---|
| Security Controls | ISO 27001 Annex A mapping | HTML / MD |
| Self-Declaration | Security posture summary | MD |
| DORA Support Pack | Third-party risk review evidence | PDF |
| Data Residency Statement | EU hosting, subprocessors | This page (Section 7) |
| SLO Documentation | Availability targets, incident process | This page (Section 4) |
| Methodology & Sources | Claim documentation, data sources | HTML |
| OpenAPI Specification | Complete API schema | YAML / JSON |
Need a custom evidence package for your procurement process?
We work with your vendor risk team to provide the specific documentation you need.
enterprise@feedoracle.io
12. Changelog
| Date | Change | Section |
|---|
| 9 Feb 2026 | Section 8 split into Subprocessors / External Data Sources / Anchoring Networks; absolute-language softened to targets; trust center restructured | 8, 2, 5 |
| 28 Jan 2026 | Initial Trust & Evidence page published | — |
Material changes to security controls, subprocessors, or data handling practices are documented here. Enterprise customers can subscribe to change notifications.