Tolar V2 & existing users
What continues
Section titled “What continues”The migration is designed to carry account balances and deployed contract state into V2. Existing users should not have to create a new identity simply because the underlying node implementation changes.
Wallet compatibility is a separate question. A wallet can display a balance yet still fail when signing or submitting a transaction.
What to verify in a wallet
Section titled “What to verify in a wallet”- It connects to the correct Tolar RPC endpoint.
- It supports the deployed interface and transaction format.
- It obtains an appropriate current fee rather than assuming a fixed price.
- It handles the network’s nonce, estimation and error behavior.
- If it uses legacy gRPC, the required compatibility gateway is available.
Never re-enter your recovery phrase into this website. Use only the wallet’s own verified recovery process if you need to change wallet software.
Contracts and integrations
Section titled “Contracts and integrations”Preserved contract state does not prove that every integration is behaviorally identical. Test call/revert handling, fee assumptions, event queries, address conversion and any dependency on historical block numbering.
Use the RPC compatibility guide and check the actual release on each network.
Finding older transactions
Section titled “Finding older transactions”V1 history is preserved through an archive commitment and history-capable nodes. Native V2 and legacy-facing block numbers differ. The history guide explains the distinction for explorers and indexers.
If something fails
Section titled “If something fails”Keep the error message, wallet version, selected network and public transaction hash or account address when relevant. Contact the project through its published channels. Do not share private keys or recovery phrases with anyone offering to fix the problem.