# see-through
Contract Registration & Autodiscovery
When you register a contract with ChainAlert, we resolve its ABI from public verification services, detect proxy patterns, discover interesting storage slots by recompiling verified source code, and analyze the contract's traits to suggest relevant detection templates. This document explains each step transparently.
Contract Resolution
Contract resolution takes an address and network, fetches the contract's ABI from public verification services, and caches it for all organizations.
$ resolve --address 0xa0b8...eb48 --network ethereum
>resolved: FiatTokenV2_2 (verified) — 83 ABI entries
Etherscan V2 API — a unified endpoint that works for Ethereum, Arbitrum, Base, and Polygon using a single chainid parameter
Only verified contracts — if the source isn't verified on Etherscan or Sourcify, registration fails. This is deliberate — unverified contracts lack the ABI needed for detection
Two-table architecture — global contracts table holds ABI data (shared), per-org org_contracts table holds labels, tags, and notes (private)
Storage Layout Autodiscovery
After resolving a contract, ChainAlert asynchronously recompiles the verified source code using the exact Solidity compiler version to extract the storage layout. It then filters for interesting variables — governance, security, and financial parameters — and makes them available for detection setup.
$ discover-layout --contract FiatTokenV2_2
>discovered 4 slots: _owner (slot 0), _paused (slot 0:20), _totalSupply (slot 1), _fee (slot 3)
Fire-and-forget — discovery runs in the background after resolution (typically 2–10 seconds)
Solidity only — Vyper and other languages are detected and marked as unsupported
Keyword-based filtering — heuristic, not semantic. Variables are filtered by name, so a variable called criticalParam won't match, but feeLimit will
Trait Detection
After registration, ChainAlert analyzes the contract's ABI to detect common patterns and makes targeted on-chain reads to gather live state.
| Trait | Detection Method | Suggested Templates |
|---|---|---|
| ERC-20 | transfer, balanceOf, totalSupply, decimals in ABI | Large Transfer, Fund Drainage, Balance Low |
| Ownable | owner() in ABI + on-chain read | Ownership Transfer |
| AccessControl | hasRole, grantRole, revokeRole in ABI | Role Change |
| Pausable | paused, pause, unpause in ABI | Pause State Change |
| Gnosis Safe | getOwners, getThreshold, nonce in ABI | Multisig Signer Change |
| Proxy (UUPS) | upgradeTo in ABI or ERC-1967 slot | Proxy Upgrade (Event + Slot) |
| ERC-721 | ownerOf, tokenURI, safeTransferFrom in ABI | Custom Event |
| ERC-1155 | balanceOfBatch, safeBatchTransferFrom in ABI | Custom Event |
On-chain reads — for detected traits, we call owner(), paused(), token metadata, and balance functions to populate the contract dashboard
Proxy detection — when the ERC-1967 implementation slot contains a non-zero address, the contract is marked as a proxy and the implementation address is stored
Template suggestions — detected traits are used to suggest relevant detection templates during setup, reducing configuration friction
Known Limitations
Only verified contracts are supported. Unverified contracts cannot be registered or monitored.
Storage layout discovery only works for Solidity contracts. Vyper, Yul, and other languages are not supported.
Layout discovery is fire-and-forget — check the layoutStatus field to know when it completes.
The keyword filter is heuristic, not semantic. Review discovered slots and add custom monitors for variables that don't match keywords.
For proxy contracts, layout discovery runs on the proxy source, not the implementation. The implementation may need separate resolution.
Trait detection uses function name matching, not signature parsing. False positives are rare but possible.
Related Documentation
Detection Templates — how each template uses resolved ABIs and discovered slots
Storage Monitoring — deep dive into storage slot polling mechanics
Supported Chains — which chains support contract resolution