Solc

solc

Direct Solidity compilation when you want the compiler, not the framework's interpretation of it.

When to use solc

Use solc when you need to:

• compile a single contract or small set of contracts directly
• produce ABI and bytecode artifacts for deployment or analysis
• confirm optimizer and compiler-version effects explicitly
• feed slither, mythril, or custom tooling with known compilation inputs

Quick Start

# Emit ABI and bytecode into a build directory
solc --abi --bin Contract.sol -o build

# Enable optimization explicitly
solc --abi --bin --optimize --optimize-runs 200 Contract.sol -o build

High-Value Workflows

Combined output for tooling

solc --combined-json abi,bin,metadata Contract.sol > combined.json

Standard JSON mode

solc --standard-json < input.json > output.json

Practical Notes

• Match the compiler version to the contract's pragma and real deployment assumptions.
• Record optimizer settings; they materially affect bytecode, findings, and source maps.
• Use framework-native compilation for large projects, then fall back to raw solc when you need explicit control.

Caveats

• Import resolution and remappings are easy to get wrong outside a framework.
• Single-file success does not mean a full project will compile cleanly.
• Compiler-version mismatch can invalidate audit conclusions very quickly.

Resources

No bundled scripts/, references/, or assets/. Use the official Solidity compiler docs for standard JSON schema, optimizer controls, and remapping behavior.