Katana | Contract Addresses — Core Network & KAT References
Katana contract address reference for core network infrastructure, KAT staking components, bridge contracts and integration verification practices.
Why contract verification matters
A correct interface can still send funds to the wrong address if contract configuration is stale or copied from another chain. Katana integrations should verify network, address, code and token metadata before enabling user transactions.
KAT ecosystem contracts
Important KAT ecosystem contracts include the KAT token, vKAT lock management, avKAT vault, gauge voting, exit queue and reward distribution components. These contracts should be treated as separate modules with different approval and interaction patterns.
Bridge infrastructure
Katana bridging uses dedicated canonical bridge contracts and can also support additional interoperability protocols. Developers should verify which route their application uses and which chain/network identifiers apply to that route.
Common EVM helpers
Katana supports common EVM helper contracts such as Multicall-style and Safe-related infrastructure. However, application code should never assume every common address is safe to use without checking Katana’s current reference.
WETH caveat
Do not assume the default OP Stack WETH predeploy is the correct WETH integration target on Katana. Katana uses productive asset infrastructure, so the current WETH contract should be taken from Katana-specific references.
Verification workflow
Before release: confirm the address on the Katana explorer, confirm bytecode or verified source where available, check token decimals and symbol, verify admin/upgradeability, and test the exact transaction path on the intended chain.
Frequently Asked Questions
Why should I verify Katana contract addresses?
Using an incorrect or stale address can send approvals or funds to the wrong contract.
Can I use the default OP Stack WETH address?
Developers should use Katana-specific WETH references rather than assuming the generic predeploy is correct.
Where should contracts be verified?
Use the Katana block explorer and current network documentation.
Should addresses be hard-coded forever?
Critical production addresses should be versioned and monitored because upgrades or integrations can change.