System modules
Stable's core protocol behavior lives in SDK modules such as x/bank, x/distribution, and x/staking. Fixed-address precompiles route Solidity calls into their native SDK handlers without duplicating the protocol logic in application contracts.
The three modules
| Module | Precompile address | Purpose |
|---|---|---|
| Bank | 0x0000…1003 (STABLE) | Token transfers, balance accounting, allowance management, mint/burn for authorized contracts. |
| Distribution | 0x0000…0801 | Staking-reward claims, reward queries, withdraw-address management. |
| Staking | 0x0000…0800 | Delegation, undelegation, redelegation, validator queries. |
| System transactions | 0x0000…9999 | Guaranteed blockspace lane queries and protocol-emitted EVM events. |
Each page above explains what the module does, when to use it, and where to find its ABI.
Why precompiles, not Solidity
Two reasons:
- Gas efficiency. A precompile runs in the protocol's native execution path. An equivalent Solidity contract would re-implement the same logic with significantly higher gas cost.
- Single source of truth. Staking, distribution, and token supply are protocol-level state. Exposing them through precompiles avoids maintaining a duplicate Solidity implementation that could drift from the SDK.
Authorization
Some precompile methods (mint, burn, protocol-level staking operations) require caller authorization. The x/precompile module maintains an on-chain whitelist, and calls from unregistered contracts revert. This keeps privileged operations governance-gated without blocking general EVM use of read/transfer methods.
Where to go next
- Bank module: Understand token transfers, allowances, and the mint/burn authorization model.
- Staking module: See how delegation and validator management reach the EVM.
- System transactions: Learn how protocol-level events like unbonding completions surface as EVM logs.