Introduction to Precompiles

Overview

This course uses precompiles to enforce network access restrictions. If you’re not already comfortable with what precompiles are and how they work, you should complete the Customizing the EVM course first (especially the Precompiles chapter).

Precompiles are “built-in contracts” backed by the VM implementation (typically Go), mapped to reserved addresses. From Solidity’s point of view, they look like normal contracts you call via an interface — but they execute faster and can expose VM-level capabilities that regular contracts can’t safely implement.

Why precompiles matter for access restriction

Access restriction isn’t a typical dApp feature — it’s a network rule. That’s why Avalanche L1s implement these controls as precompiles:

• Performance & gas: checks happen at the VM level and are efficient.
• Security: the permission logic is centralized, audited, and not re-implemented in every contract.
• Consistency: multiple precompiles can share the same permission model (via a common interface).

How you’ll use precompiles in this course

We’ll focus on two default precompiles that use the same underlying permission model:

• Transaction AllowList: controls who can submit transactions to the chain.
• Contract Deployer AllowList: controls who can deploy smart contracts.

In the next lesson, you’ll learn the shared permission model these precompiles use: the AllowList interface.

Summary

Key points:

• Precompiles are VM-implemented contracts at reserved addresses, callable like normal Solidity contracts.
• Avalanche L1s use precompiles for privileged network behavior (like access restriction).
• Many default precompiles share a common permission pattern, which we cover next.