Smart Contract Deployment to Solana

Deploying Smart Contracts to Solana

Deployment on Solana is fundamentally different from Ethereum. There is no concept of "contract" in EVM sense — there are programs (executable accounts) and accounts (data). A program does not store state inside itself: all state lives in separate data accounts, owned by the program. This changes the deployment approach and requires planning account structure upfront.

Tooling: Anchor Framework

Anchor is the standard framework for Solana development. If writing native Rust without Anchor, multiply development time by 3 and add manual instruction deserialization. Anchor handles most boilerplate and generates IDL (Interface Definition Language) — analogous to ABI for EVM.

# Build
anchor build

# Deploy to mainnet-beta
anchor deploy --provider.cluster mainnet-beta \
  --provider.wallet ~/.config/solana/deployer-keypair.json

Deployment Cost: Rent-Exemption

In Solana, storing data in an account costs SOL via rent. To prevent account deletion, you must maintain minimum balance (rent-exemption). Size of program account is proportional to bytecode size:

# Estimate cost before deployment
solana rent <bytes>
# Example: 200KB program ≈ 1.4 SOL rent-exemption

This is important to plan: deployment budget needs to account not only for transaction fees (~0.00025 SOL), but also rent-exemption for program account storage.

Buffer Account and Two-Stage Deployment

Solana limits single transaction size. Programs larger than few kilobytes deploy in multiple stages via buffer account:

1. Buffer account created
2. Bytecode uploaded in chunks via solana program write-buffer
3. Program deployed from buffer atomically

Anchor does this automatically. For manual deployment via CLI:

solana program deploy \
  --program-id target/deploy/my_program-keypair.json \
  --buffer /path/to/buffer-keypair.json \
  target/deploy/my_program.so

Upgradeable Programs

By default Anchor creates upgradeable program with upgrade authority equal to deployer keypair. This is correct for development but not for production:

# View current upgrade authority
solana program show <PROGRAM_ID>

# Transfer authority to multisig (Squads Protocol — standard multisig on Solana)
solana program set-upgrade-authority <PROGRAM_ID> \
  --new-upgrade-authority <SQUADS_MULTISIG_ADDRESS>

After transferring authority to multisig any program update requires M-of-N signatures. This is critical for mainnet — single key as upgrade authority is single point of failure.

Immutable program — if logic is final and updates not planned:

solana program set-upgrade-authority <PROGRAM_ID> --final

This is irreversible. After this program cannot be updated or closed.

Verification and IDL

After deployment upload IDL on-chain — this lets other developers and tools (Explorer, Anchor clients) automatically know program interface:

anchor idl init --filepath target/idl/my_program.json <PROGRAM_ID> \
  --provider.cluster mainnet-beta

Source code verification — via solana-verify (OtterSec). Publishes proof that on-chain bytecode matches specific Git commit:

solana-verify verify-from-repo \
  --program-id <PROGRAM_ID> \
  https://github.com/yourorg/yourrepo

Checklist Before Mainnet Deployment

• Full test coverage on localnet and devnet
• Audit (OtterSec, Neodyme, Trail of Bits — specialize in Solana)
• Program derived addresses (PDA) checked for collisions
• Check integer overflow (Solana uses checked arithmetic, but ensure overflow-checks = true in Cargo.toml)
• Upgrade authority transferred to multisig
• Sufficient SOL on deployer wallet accounting for rent-exemption
• Monitoring via Helius webhooks or Shyft on critical instructions