Katana | Read Balances & Wrap ETH to WETH
Read native and ERC-20 balances on Katana and wrap ETH into the network-specific WETH implementation safely with EVM tooling.
Goal
Read wallet balances accurately and convert ETH to the correct Katana WETH contract rather than assuming a generic predeploy address.
Before you begin
Confirm that your wallet is connected to Katana, that you have enough ETH for gas, and that token addresses or positions match the intended network. Review approvals before signing and avoid copying addresses from unverified sources.
Step-by-step workflow
Read native ETH with the account balance RPC.
Read ERC-20 balances using balanceOf and token decimals.
Resolve the current Katana WETH address from network configuration.
Call deposit/wrap with the intended ETH amount.
Verify the WETH balance after confirmation.
What changes onchain
The transaction updates a Katana smart-contract position rather than only changing the interface. Wallet prompts should therefore be checked for contract address, token amount, approvals and network before signing.
Risk and troubleshooting
Cross-chain, liquidity, smart-contract and configuration risks depend on the specific workflow. Always validate network, contract, token and expected output before signing.
- Wrong network or token address.
- Insufficient gas or token balance.
- Stale interface state after a transaction.
- Unexpected approval scope.
- Market, liquidity or exit conditions changing after entry.
Verification after completion
Check the transaction on Katana’s explorer, refresh balances from the chain and confirm that the expected position or token amount changed. For multi-step workflows, verify each transaction before continuing.
Frequently Asked Questions
What is the first safety check?
Verify the active Katana network and the exact contract or token address involved.
Should approvals be unlimited?
Use the smallest practical approval scope unless the application clearly requires a different pattern.
How do I verify completion?
Check the confirmed transaction and resulting onchain state, not only the interface message.
What if the UI disagrees with the explorer?
Treat onchain explorer/RPC state as authoritative and investigate caching or indexing lag in the interface.