Precompiles are natively executed system interfaces exposed at fixed addresses. They are used when computation is too costly in EVM bytecode (e.g., SNARK verification) or when contracts must interface with native chain modules without re-implementing them in Solidity. For canonical addresses, ABI artifacts, import guidance, function signatures, events, reverts, and gas behavior, see the Precompile ABI Reference. c8ntinuum’s precompiles are organized into five families. c8ntinuum also includes custom Cosmos modules for validator incentives, validator creation policy, chain availability controls, and IBC safety controls.

Cross-chain Verification

When to use ICS02, ICS20, SP1 verifiers, and heterogeneous verification helpers

Cosmos Module Access

Bank, Staking, Distribution, Governance, Slashing, ERC-20 surfaces (catalogued below)

Custom Modules

Validator rewards, minimum self-delegation, circuit breaker, IBC controls (catalogued below)

Cryptographic Verification

Signature, VRF, threshold, and post-quantum verification guidance

Hashing

Native hashing surfaces and encoding guidance

Data Ergonomics

JSON, address conversion, and address-compression concepts

​
Cross-Chain Verification & Interoperability

Trust-minimized cross-chain communication via light-client semantics, zkVM verification, and heterogeneous chain support.
PrecompilePurposeDetails
ics02Light-client verificationEnables contracts to update verified remote consensus views and validate proof-carrying statements about remote state
ics20IBC fungible token transfersStandardized cross-chain token transfer logic, composable payments and asset movement
solanatxSolana transaction parsingCanonical parser for Solana transactions and instructions as structured data
sp1verifiergroth16Groth16 proof verification (SP1)Verifies Groth16 proofs from SP1 programs — “prove off-chain, verify on-chain”
sp1verifierplonkPlonk proof verification (SP1)Verifies Plonk proofs from SP1 programs, offering flexibility in proof size and verification cost

​
Native Module Access

Cosmos-native modules and chain economics accessible from Solidity for hybrid Cosmos-EVM applications.
PrecompilePurposeDetailsReference
bankNative asset accountingBalance, supply, and denomination logic as first-class EVM operationsDetails
erc20ERC-20 surface for native assetsBridges Ethereum’s token interface into the native token modelDetails
werc20Wrapped native tokenWETH-like wrapper for the native token supporting ERC-20-only flowsDetails
stakingDelegation state interfaceStaking operations and state queries for liquid staking, vaults, automationDetails
distributionRewards accountingProgrammatic reward handling and auto-compounding strategiesDetails
slashingFault observabilitySlashing and jailing semantics for validator risk assessmentDetails
govGovernance interfaceProposal and voting workflows, governance-driven automationDetails
valrewardsCustom incentive surfaceSpecialized validator reward logic and incentive designDetails
bech32Address bridgeConversion between bech32 and EVM address representationsDetails

​
Custom Modules

c8ntinuum modules add chain-specific policy and operational controls around the standard Cosmos/EVM stack.
ModulePurposeDetails
x/valrewardsValidator reward points and epoch payoutsValidator Rewards
x/msdcheckMinimum self-delegation floor across staking entry pointsMinimum Self-Delegation Check
x/circuitGlobal chain availability gate for native and EVM transaction routesCircuit Breaker
x/ibcbreakerOperator-controlled IBC availability gate for restricted outbound IBC initiation pathsIBC Breaker
x/ibcratelimiterextGovernance-managed operator whitelist for IBC rate-limiter mutation APIsIBC Rate-Limiter Extension

​
Cryptographic Constructions

Advanced signature schemes, threshold protocols, and verifiable randomness.
PrecompilePurposeDetails
ed25519EdDSA verificationEd25519 signatures for Solana-style and EdDSA-based ecosystems
p256NIST P-256 verificationMainstream curve for enterprise crypto and modern authentication
schnorrSchnorr over secp256k1Aggregation-friendly signatures in a widely deployed curve
schnorrkelSchnorrkel / sr25519Verification for Schnorrkel-style ecosystem signatures
frostThreshold signature sharesFROST primitives for threshold signing and share verification
ecvrfVerifiable Random FunctionsPublicly verifiable randomness for lotteries, leader election, and randomness beacons
pqmldsaPost-quantum (ML-DSA)Lattice-based PQ signature verification (NIST standardized)
pqslhdsaPost-quantum (SLH-DSA)Hash-based PQ signatures as complementary design point

​
Hashing Surfaces

Standardized and ZK-efficient hashing aligned with modern proof systems.
PrecompilePurposeDetails
sha3hashSHA-3 familyStandardized hashing for commitments and cryptographic constructions
blake2bhashBLAKE2bHigh-performance hashing for modern protocols
poseidonhashPoseidon (ZK-efficient)Optimized for zero-knowledge circuits — matches off-chain proving systems
gnarkhashgnark-crypto alignedPractical hash utilities for proof systems and zk engineering

​
Data Handling & Ergonomics

Developer ergonomics and UX improvements for multi-domain applications.
PrecompilePurposeDetails
jsonStructured payload parsingInterpret structured messages without brittle custom parsers
addresstableAddress compressionShort-hands for frequently used addresses, reducing calldata and gas

​
Design Notes

  • Precompiles are implemented as native code for gas-efficiency and correctness
  • Address assignments are stable by design to preserve composability across upgrades
  • When building protocols that depend on specific precompile behavior (zk verification, PQ signatures), refer to versioned specifications and tests

​
Usage in Smart Contracts

// Pseudocode: import the canonical interfaces for the target release.
IBank constant bank = IBank(BANK_PRECOMPILE_ADDRESS);
IStaking constant staking = IStaking(STAKING_PRECOMPILE_ADDRESS);

// Query native token-pair balances
bank.balances(msg.sender);

// Delegate to a validator
staking.delegate(msg.sender, validatorAddr, amount);
For exact return structs, imports, events, reverts, and gas behavior, use Precompile ABI Reference.
Cosmos module precompiles use the chain’s native decimal precision. c8ntinuum’s base denom is ctm with exponent 18; check each precompile’s expected amount format before interacting with it.