Modules & Precompiles

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.

Precompile	Purpose	Details
ics02	Light-client verification	Enables contracts to update verified remote consensus views and validate proof-carrying statements about remote state
ics20	IBC fungible token transfers	Standardized cross-chain token transfer logic, composable payments and asset movement
solanatx	Solana transaction parsing	Canonical parser for Solana transactions and instructions as structured data
sp1verifiergroth16	Groth16 proof verification (SP1)	Verifies Groth16 proofs from SP1 programs — “prove off-chain, verify on-chain”
sp1verifierplonk	Plonk 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.

Precompile	Purpose	Details	Reference
bank	Native asset accounting	Balance, supply, and denomination logic as first-class EVM operations	Details
erc20	ERC-20 surface for native assets	Bridges Ethereum’s token interface into the native token model	Details
werc20	Wrapped native token	WETH-like wrapper for the native token supporting ERC-20-only flows	Details
staking	Delegation state interface	Staking operations and state queries for liquid staking, vaults, automation	Details
distribution	Rewards accounting	Programmatic reward handling and auto-compounding strategies	Details
slashing	Fault observability	Slashing and jailing semantics for validator risk assessment	Details
gov	Governance interface	Proposal and voting workflows, governance-driven automation	Details
valrewards	Custom incentive surface	Specialized validator reward logic and incentive design	Details
bech32	Address bridge	Conversion between bech32 and EVM address representations	Details

Custom Modules

c8ntinuum modules add chain-specific policy and operational controls around the standard Cosmos/EVM stack.

Module	Purpose	Details
x/valrewards	Validator reward points and epoch payouts	Validator Rewards
x/msdcheck	Minimum self-delegation floor across staking entry points	Minimum Self-Delegation Check
x/circuit	Global chain availability gate for native and EVM transaction routes	Circuit Breaker
x/ibcbreaker	Operator-controlled IBC availability gate for restricted outbound IBC initiation paths	IBC Breaker
x/ibcratelimiterext	Governance-managed operator whitelist for IBC rate-limiter mutation APIs	IBC Rate-Limiter Extension

Cryptographic Constructions

Advanced signature schemes, threshold protocols, and verifiable randomness.

Precompile	Purpose	Details
ed25519	EdDSA verification	Ed25519 signatures for Solana-style and EdDSA-based ecosystems
p256	NIST P-256 verification	Mainstream curve for enterprise crypto and modern authentication
schnorr	Schnorr over secp256k1	Aggregation-friendly signatures in a widely deployed curve
schnorrkel	Schnorrkel / sr25519	Verification for Schnorrkel-style ecosystem signatures
frost	Threshold signature shares	FROST primitives for threshold signing and share verification
ecvrf	Verifiable Random Functions	Publicly verifiable randomness for lotteries, leader election, and randomness beacons
pqmldsa	Post-quantum (ML-DSA)	Lattice-based PQ signature verification (NIST standardized)
pqslhdsa	Post-quantum (SLH-DSA)	Hash-based PQ signatures as complementary design point

Hashing Surfaces

Standardized and ZK-efficient hashing aligned with modern proof systems.

Precompile	Purpose	Details
sha3hash	SHA-3 family	Standardized hashing for commitments and cryptographic constructions
blake2bhash	BLAKE2b	High-performance hashing for modern protocols
poseidonhash	Poseidon (ZK-efficient)	Optimized for zero-knowledge circuits — matches off-chain proving systems
gnarkhash	gnark-crypto aligned	Practical hash utilities for proof systems and zk engineering

Data Handling & Ergonomics

Developer ergonomics and UX improvements for multi-domain applications.

Precompile	Purpose	Details
json	Structured payload parsing	Interpret structured messages without brittle custom parsers
addresstable	Address compression	Short-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.

Learn

Core Concepts

Chain Architecture

Execution and EVM

Interoperability and IBC

Transaction Lifecycle

Modules & Precompiles

Cross-chain Verification

Cosmos Module Access

Custom Modules

Cryptographic Verification

Hashing

Data Ergonomics

Cross-Chain Verification & Interoperability

Native Module Access

Custom Modules

Cryptographic Constructions

Hashing Surfaces

Data Handling & Ergonomics

Design Notes

Usage in Smart Contracts

Cross-chain Verification

Cosmos Module Access

Custom Modules

Cryptographic Verification

Hashing

Data Ergonomics

​Cross-Chain Verification & Interoperability

​Native Module Access

​Custom Modules

​Cryptographic Constructions

​Hashing Surfaces

​Data Handling & Ergonomics

​Design Notes

​Usage in Smart Contracts

Cross-Chain Verification & Interoperability

Native Module Access

Custom Modules

Cryptographic Constructions

Hashing Surfaces

Data Handling & Ergonomics

Design Notes

Usage in Smart Contracts