Asymmetric Research Asymmetric Research × Solana Foundation Solana Foundation

Infrastructure

Infrastructure covers the off-chain surface attackers probe first, from domains and web applications to key storage, backend services, and RPC. A protocol with a flawless program can still lose user funds through a hijacked registrar account.

An attacker who compromises the registrar account can redirect the domain and serve users a hostile frontend from the real URL, without touching the program.

I1.1

Domain registrar accounts are hardened with hardware 2FA and restricted account recovery.

I1.2

Domain lock is enabled to prevent unauthorized transfers.

I1.3

Registrar access is limited to the fewest people who need it, and access is logged.

I1.4

Expiration monitoring is in place.

Most users meet the protocol through its frontend. A compromised page can rewrite transactions before a wallet ever signs them, so the web surface needs the same rigor as the program.

I2.1

Frontend and API surfaces undergo regular penetration testing.

I2.2

The web application sets CSP headers.

I2.3

The web application uses subresource integrity.

I2.4

The web application validates input.

These controls govern where keys for privileged operations live and who can use them. Plaintext storage in a file, an environment variable, or a repository turns every reader of that location into a potential signer.

I3.1

Cryptographic keys for privileged operations are stored in an HSM or a cloud KMS.

I3.2(critical control)

Keys are never stored in plaintext.

I3.3(critical control)

Keys are never stored in environment variables.

I3.4(critical control)

Keys are never stored in source control.

I3.5

Key generation follows a documented ceremony.

I3.6

A rotation schedule is in place and enforced.

I3.7

Access to signing infrastructure requires multi-party authorization.

I3.8

Backup and recovery procedures are tested regularly.

Cranks, keepers, liquidation bots, relayers, and indexers run on ordinary servers with ordinary failure modes. Each needs patching, credential hygiene, redundancy, and a documented answer for what happens when it goes down.

I4.1

All off-chain components are enumerated, including cranks, keepers, liquidation bots, relayers, indexers, and APIs. Availability requirements and failure impact are documented for each.

I4.2

Services run with redundancy and failover.

I4.3

Secrets management uses dedicated tooling rather than shared credentials.

I4.4

Server and container access follows least privilege, with audit logging.

I4.5

Cloud infrastructure is reviewed for misconfigurations such as public storage buckets and overly permissive IAM policies.

Every off-chain component reaches the chain through RPC. When the only provider degrades, liquidations, monitoring, and user exits degrade with it.

I5.1

The RPC provider strategy is documented as self-hosted, third-party, or hybrid.

I5.2

Single-provider dependencies are avoided on critical paths.

I5.3

Fallback RPC endpoints are configured and tested.

I5.4

Rate limits and provider SLAs are understood relative to the protocol’s throughput requirements.

I5.5

Validator client diversity considerations are documented where relevant.