Skip to content

Security: dylanpersonguy/dcc-aggregator

Security

SECURITY.md

Security Policy

Threat Model

Smart Contract Layer

Attack Vector Risk Mitigation
Reentrancy N/A RIDE is single-threaded; no reentrancy possible
Integer overflow/underflow Low RIDE Int is 64-bit signed; all math checked at boundaries
First-depositor inflation attack Low Dead shares (1000) burned on bootstrap
Share price manipulation Low Atomic on-chain calculation; no external oracle dependency
Unauthorized callable invocations Medium Role-based access via VaultRegistry; checked on every call
Fee extraction beyond caps Low Hard-coded max caps (mgmt 5%, perf 30%, withdraw 1%)
Strategy rug / malicious strategy Medium Strategy must be approved by admin; guardian emergency exit
Pause bypass Low Only withdraw() works when paused (user safety feature)
Flash loan attacks N/A DCC does not have atomic composability; no flash loans

Operational Layer

Attack Vector Risk Mitigation
Keeper key compromise Medium Keeper can only harvest/rebalance — cannot withdraw user funds
Admin key compromise High Use multi-sig (planned); minimize admin operations
Stale data / node manipulation Medium SDK retries + multiple node endpoints (planned)
Keeper DDoS Low Rate limiting, idempotency guards, cooldown periods
Webhook interception Low HTTPS-only webhook URLs; non-sensitive data in alerts

Frontend Layer

Attack Vector Risk Mitigation
XSS Low React auto-escapes; CSP headers; no dangerouslySetInnerHTML
Transaction parameter tampering Low All amounts verified on-chain; frontend is convenience only
Phishing / fake site Medium Domain verification; wallet signature display (planned)

Access Control Matrix

Action Admin Guardian Keeper Strategist User
Initialize registry
Register vault
Set vault strategy
Approve strategy
Update fee parameters
Grant / revoke roles
Pause vault
Pause global
Emergency exit
Harvest
Push to strategy
Recall from strategy
Report harvest
Deposit
Withdraw
Withdraw (paused vault)

Key Management Guidelines

  • Admin key: Should be a multi-sig or hardware wallet. Used rarely for configuration changes.
  • Guardian key: Separate from admin. Trusted party who can react quickly to emergencies.
  • Keeper key: Dedicated account with minimal balance. Only needs enough DCC for invoke fees.
  • Strategy contracts: Each deployed to its own account. No seed phrases stored in plaintext.

Secure Development Practices

  • All financial math uses BigInt — no floating point anywhere in the stack
  • No eval(), no dynamic require(), no shell command execution from user input
  • Environment secrets loaded via env vars, never committed to repo
  • .env.example ships with placeholder values only
  • Docker images run as non-root users
  • K8s secrets should use SealedSecrets or external secret managers

Incident Response

  1. Detection: Health monitor detects anomaly → alerts via webhook
  2. Assessment: Guardian reviews on-chain state via explorer
  3. Containment: Guardian calls pauseVault() or pauseGlobal()
  4. Recovery: Admin assesses damage; calls emergencyMode() if needed
  5. Post-mortem: Document root cause; update contracts if necessary

Audit Status

  • Internal code review (all contracts)
  • Internal code review (SDK + keeper)
  • External smart contract audit
  • External infrastructure audit
  • Bug bounty program launched
  • Formal verification of share accounting math

Responsible Disclosure

If you discover a security vulnerability, please report it to: security@decentralchain.io

Do NOT open a public GitHub issue for security vulnerabilities.

There aren’t any published security advisories