Security control framework

All code changes undergo security-focused review with documented sign-off before deployment. Review covers both correctness and security properties.

Critical code paths and major changes are reviewed by independent security firms. Findings are tracked to resolution, and the audit scope covers the currently deployed version.

An active, monitored bug bounty program with defined scope and clear severity tiers. Alternatively, a published security contact with a committed triage timeline. The program binary includes solana-security-txt metadata such as contact, policy, and source URL.

On-chain safeguards that limit the blast radius of a single vulnerability or compromise, such as rate limits on transfer volume, per-epoch caps, circuit breakers triggered by invariant violations, reduced unnecessary composability like CPI on admin instructions, and graduated withdrawal limits.

Continuous security tooling integrated into CI/CD to detect common Solana footguns, including fuzz testing, static analysis, property-based testing, formal verification, or AI-assisted review.

All privileged roles are documented with explicit enumeration of their capabilities. Roles follow least-privilege principles, and no single role can both modify parameters and move funds. Role assignments are verifiable on-chain. Individual actors should not hold overlapping duties that create perverse incentives or widen the attack surface.

Program upgrade authority is clearly defined as immutable, multisig-controlled, or governance-gated. If upgradeable, the upgrade path is documented and users can verify the deployed version against source via the verified builds API. Authority transfer and revocation procedures exist.

Privileged actions are subject to enforced on-chain timelocks with duration proportional to impact. Emergency bypass conditions are explicitly defined, documented, and scoped. Timelock duration and bypass history are publicly auditable.

Multisig threshold, total signer count, and signer identity are documented. Threshold follows n-of-m best practices relative to signer count. Key rotation and signer removal procedures are in place. No single entity controls a majority of keys. Signer hardware wallets have vendor diversity.

Economic parameters such as collateral factors, liquidation thresholds, fee structures, and rate models are governed by appropriate roles with documented change procedures. Parameter bounds and downstream user impact are specified. Historical parameter changes are logged and publicly accessible.

All external dependencies, including oracles, bridges, keeper networks, programs invoked via CPI (with transitive CPI targets and Token-2022 transfer-hook programs or authorities), and off-chain data sources, are enumerated with explicit trust assumptions. For every dependency the failure mode is specified, covering what happens if it lies, goes stale, or disappears. Trust boundaries distinguish what the protocol verifies from what it assumes correct.

Price feeds use multiple independent sources where feasible. The aggregation method is documented, whether median, TWAP, or weighted. Confidence intervals or deviation thresholds are enforced on-chain. Known threat vectors for the specific setup are identified and mitigated, including low-liquidity Pyth feeds, Switchboard permissioned feeds, slot versus timestamp on validator outage, and pull-oracle failures during congestion. Oracle selection rationale is documented.

Maximum acceptable age for every external input is defined and enforced on-chain. Fallback behavior when inputs are stale or unavailable is specified. Liveness monitoring is in place for all critical feeds.

Impact of a single compromised dependency such as a program, oracle, or token is bounded. No single failure can unnecessarily drain the protocol. Exposure per external dependency is capped or isolated through per-market oracle assignment, bridge deposit limits, and maximum exposure per collateral type.

Domain registrar accounts are hardened with hardware 2FA and restricted account recovery. Domain lock is enabled to prevent unauthorized transfers. Registrar access is limited to minimum necessary personnel, with access logged. Expiration monitoring is in place.

Frontend and API surfaces undergo regular penetration testing. Web infrastructure uses secure-by-default frameworks with CSP headers, subresource integrity, and input validation.

Cryptographic keys for privileged operations are stored in HSMs or cloud KMS, never in plaintext, environment variables, or source control. Key generation follows a documented ceremony. A rotation schedule exists and is enforced. Access to signing infrastructure requires multi-party authorization. Backup and recovery procedures are tested on a recurring basis.

All off-chain components, including cranks, keepers, liquidation bots, relayers, indexers, and APIs, are enumerated with availability requirements and failure impact documented. Services run with redundancy and failover. Secrets management uses dedicated tooling such as Vault or cloud-native KMS rather than shared credentials. Server and container access follows least-privilege with audit logging. Cloud configuration is reviewed for misconfigurations such as public buckets and overly permissive IAM.

RPC provider strategy is documented as self-hosted, third-party, or hybrid. Single-provider dependencies are avoided on critical paths. Fallback RPC endpoints are configured and tested. Rate limits and provider SLAs are understood relative to throughput requirements. Validator client diversity considerations are documented where relevant.

All dependencies are pinned to exact versions with lockfiles committed to source control. Dependency updates are deliberate and reviewed. Crate and package provenance is verified. Transitive dependencies are understood and tracked. Registry publish access for crates.io and npm is protected with hardware keys and restricted to minimum maintainers.

Main and release branches enforce protection rules such as no direct pushes, required status checks, and no single-administrator override. Repository access follows least-privilege. Org-level settings such as SSO, 2FA, and outside-collaborator policy are hardened.

All production code changes require review from at least one independent reviewer. Review cannot be bypassed or self-approved for any path that leads to deployment.

Release artifacts are cryptographically signed. Builds are reproducible and verifiable against on-chain program hashes using solana-verify or equivalent. Verification status is monitored and re-verified after every upgrade. The release process is documented end to end, covering who triggers, what signs, and where artifacts are published.

Pipeline configuration is version-controlled and review-gated. Secrets are scoped to specific pipelines. Builds run on hardened, ephemeral infrastructure. Third-party actions and plugins are pinned to specific versions. Pipeline logs are retained for audit.

Endpoint detection and response and mobile device management are deployed across all team devices. Timely OS patching, disk encryption, and other critical OS controls are enforced. Offboarding includes device audit and remote wipe. Endpoint compliance is enforced, not assumed.

Signers use hardware wallets on dedicated devices. Transactions are verified out-of-band before signing, for example through a separate channel confirming details or an alternative Squads UI. Signing procedures are documented with clear expectations for what signers must verify. Signer availability and backup procedures exist.

All internal systems sit behind SSO with hardware-backed 2FA. Access is provisioned on a least-privilege basis. Onboarding, offboarding, and eviction checklists exist and are enforced. Access reviews are conducted periodically to catch stale permissions.

All protocol-controlled channels such as X, Discord, Telegram, and email are secured with hardware 2FA where possible. Discord bot permissions and webhook access are audited and restricted. Admin access is restricted and logged. Shared credentials are avoided. Channel recovery procedures are documented for the event of a compromise.

Operational and reserve funds are held in multisig wallets with appropriate thresholds. Spending limits and approval workflows are defined. Fund movements are logged and reconciled. No single individual can unilaterally move protocol funds.

All systems such as SaaS, on-prem, and laptops are inventoried and known, with clear owners assigned. Sensitive data in each system is understood, cataloged, and documented. Inventory is kept current through onboarding and offboarding processes and periodic review.

Critical program state changes, irregular multisig proposals including durable nonce creation, large value transfers, upgrade-authority changes on dependency programs, transfer-hook upgrades on held tokens, and anomalous transaction patterns are tracked in real time. Frontend and API availability are monitored. TVL deviations, liquidity shifts, and governance actions trigger alerts. Coverage spans all deployed environments, not just mainnet.

On-chain safeguards trigger automatically when invariants are violated or thresholds are breached, such as per-epoch transfer caps and TVL drawdown limits. Circuit breakers are granular where possible, pausing affected markets rather than the entire protocol. Trigger conditions and reset procedures are documented.

A documented IR plan with assigned roles, escalation paths, and communication templates. The playbook covers common scenarios such as compromised upgrade authority, exploit in progress, oracle failure, frontend compromise, and key compromise. A post-mortem process with root-cause analysis and a public disclosure timeline is defined. A pause authority with documented activation procedures exists for emergency use.

A 24/7 on-call rotation with defined response-time SLAs. Alerting routes to PagerDuty or equivalent with escalation if unacknowledged. Alert fatigue is managed through tuning and severity tiering. Contact information is current and tested.

Relationships with security firms and ecosystem contacts are established before an incident occurs. The responsible-disclosure process is published. The protocol has a known point of contact for external researchers. Cross-protocol channels exist for coordinated response to systemic events.

Critical systems are identified and onboarded to centralized logging, including endpoints, network devices, identity systems, cloud platforms, applications, and security tooling. New systems are evaluated for logging requirements before production. Log sources are prioritized by risk and criticality.

Logs are centrally collected in near real-time. Log integrity is protected through encryption in transit and access controls. Retention periods meet regulatory and business requirements.

Ingested logs are normalized to a standard schema for consistent analysis. Logs are enriched with contextual metadata where available, such as asset criticality, user identity, and threat-intelligence indicators. Parsing rules are reviewed periodically.

Detection rules are implemented for defined use cases with severity classification. Rules are tuned regularly to manage false-positive and false-negative rates. Changes to detection logic follow change-management procedures.

Alerts route through a defined pipeline of automated triage, ticket creation, and notification to response teams. High- and critical-severity alerts trigger immediate paging. Escalation procedures and response SLAs are documented.