Author: dnkf7sdc72rk

AVXTO Wallet requires an Etherscan API key in order to enable BNB chain access. This is because AVXTO is a thin wallet, not a full node, so we need to load block and transaction data from an indexing service. Etherscan is one of the largest providers of indexing APIs for several chains.

In this article we’ll create an Etherscan API key and configure it in AVXTO Wallet.

Introduction

Etherscan is the most widely used block explorer for the Ethereum network, offering a REST API that lets developers, wallets, and applications query blockchain data programmatically — balances, transaction history, token transfers, gas prices, contract source code, and more. To use this API, you need an API key. This guide walks through why you need one, how to create it, how to configure it securely, and how to use it to power wallet-style functionality.

---

1. Why You Need an Etherscan API Key

Etherscan’s API is free to use for most endpoints, but it still requires authentication via an API key for several reasons:

• Rate limiting: Keys let Etherscan enforce fair usage limits (typically 5 calls/second and 100,000 calls/day on the free tier) instead of blocking access entirely.
• Abuse prevention: Keys tie usage to an identifiable account, discouraging scraping and denial-of-service behavior.
• Analytics and support: Etherscan can track usage patterns per key, which helps with debugging and support requests.
• Access to premium features: Some advanced endpoints (higher throughput, additional data) are unlocked through paid tiers tied to your key.

Without a valid key, most API requests will fail or return an error indicating a missing or invalid API key.

---

2. Creating an Etherscan Account and API Key

Step 1: Register an Account

1. Go to https://etherscan.io/register.
2. Enter a username, email address, and password.
3. Verify your email address via the confirmation link Etherscan sends you.

Step 2: Log In and Navigate to the API Keys Page

1. Log in at https://etherscan.io/login.
2. Click your username in the top-right corner, then select “API Keys” from the dropdown menu (or go directly to https://etherscan.io/myapikey).

Step 3: Generate a New API Key

1. Click “+ Add”.
2. Give the key an identifiable label (e.g., my-wallet-app-prod, portfolio-tracker-dev). Use descriptive names if you plan to create multiple keys for different apps or environments.
3. Click “Create New API Key”.
4. Your key will appear in the table as a long alphanumeric string. Copy it and store it somewhere safe — you will not need to re-generate it unless it’s compromised, but you should avoid pasting it into public places.

Tip: Create separate keys for development and production environments. This makes it easy to revoke or rotate one without affecting the other.

---

3. Understanding Etherscan’s API Structure

Etherscan’s V2 API unifies access across 50+ supported chains (Ethereum mainnet, testnets, and many EVM-compatible chains like BNB Chain, Polygon, Arbitrum, etc.) through a single endpoint and a single API key, differentiated by a chainid parameter.

Base endpoint:

https://api.etherscan.io/v2/api

A typical request looks like this:

https://api.etherscan.io/v2/api
   ?chainid=1
   &module=account
   &action=balance
   &address=0xYourWalletAddressHere
   &tag=latest
   &apikey=YourApiKeyToken

Key parameters:

• chainid — numeric chain ID (1 = Ethereum mainnet, 56 = BNB Chain, 137 = Polygon, etc.)
• module — API category (account, contract, transaction, stats, gastracker, etc.)
• action — the specific method within that module (balance, txlist, tokentx, etc.)
• apikey — your personal API key

---

4. Configuring the API Key for Wallet Use

If you’re building or configuring a wallet application (or a script to track a wallet) that queries Etherscan, here’s how to wire the key in safely.

Step 1: Store the Key as an Environment Variable

Never hardcode your API key directly into source code, especially if that code will be committed to a public repository. Instead, use an environment variable.

On macOS/Linux:

export ETHERSCAN_API_KEY="YourApiKeyToken"

On Windows (PowerShell):

setx ETHERSCAN_API_KEY "YourApiKeyToken"

Using a .env file (common for Node.js/Python projects):

ETHERSCAN_API_KEY=YourApiKeyToken

Then add .env to your .gitignore file so it’s never committed to version control.

Step 2: Load the Key in Your Application

Node.js example (using dotenv and axios):

require('dotenv').config();
const axios = require('axios');

const API_KEY = process.env.ETHERSCAN_API_KEY;
const walletAddress = '0xYourWalletAddressHere';

async function getWalletBalance() {
  const url = `https://api.etherscan.io/v2/api?chainid=1&module=account&action=balance&address=${walletAddress}&tag=latest&apikey=${API_KEY}`;
  const response = await axios.get(url);
  const balanceInWei = response.data.result;
  const balanceInEth = balanceInWei / 1e18;
  console.log(`Balance: ${balanceInEth} ETH`);
}

getWalletBalance();

Python example (using python-dotenv and requests):

import os
import requests
from dotenv import load_dotenv

load_dotenv()

API_KEY = os.getenv("ETHERSCAN_API_KEY")
wallet_address = "0xYourWalletAddressHere"

url = "https://api.etherscan.io/v2/api"
params = {
    "chainid": 1,
    "module": "account",
    "action": "balance",
    "address": wallet_address,
    "tag": "latest",
    "apikey": API_KEY,
}

response = requests.get(url, params=params)
data = response.json()
balance_eth = int(data["result"]) / 1e18
print(f"Balance: {balance_eth} ETH")

Step 3: Test the Configuration

Run your script or application and confirm you get a valid JSON response with "status": "1" and a result field populated with data. A "status": "0" response usually means an invalid key, malformed request, or rate limit issue — check the "message" field for details.

---

5. Common Wallet-Related API Calls

Once your key is configured, here are some of the most useful endpoints for wallet functionality:

Purpose	Module/Action	Example Use
Get ETH balance	account / balance	Show wallet’s native token balance
Get balances for multiple addresses	account / balancemulti	Portfolio dashboards
Get normal transaction history	account / txlist	Transaction history view
Get internal transactions	account / txlistinternal	Contract-triggered transfers
Get ERC-20 token transfers	account / tokentx	Token activity feed
Get ERC-721/1155 transfers	account / tokennfttx / token1155tx	NFT activity feed
Get current gas prices	gastracker / gasoracle	Gas fee estimator
Get contract ABI	contract / getabi	Interact with smart contracts

---

6. Security Best Practices

• Never expose your key in frontend/client-side code. If a wallet app runs in the browser, route Etherscan requests through your own backend server so the key stays server-side.
• Restrict key usage where possible. Use separate keys per app/environment so you can revoke one without disrupting others.
• Rotate keys periodically, especially if you suspect a leak (e.g., accidentally committed to a public GitHub repo).
• Monitor usage via the Etherscan API Keys dashboard to catch unexpected spikes that might indicate misuse.
• Respect rate limits. Implement request throttling or caching in your wallet app to avoid hitting the 5 calls/second cap, especially when polling balances or transaction history repeatedly.
• Handle errors gracefully. Build retry logic with backoff for rate-limit errors (status: 0, message: "NOTOK") rather than hammering the API.

---

7. Troubleshooting Common Issues

Problem	Likely Cause	Fix
"Invalid API Key"	Key mistyped, expired, or not yet propagated	Double-check the key string; wait a few minutes after creation
"Max rate limit reached"	Too many requests per second	Add delay/throttling between calls
Empty result array	Wrong chain ID or address with no activity	Confirm chainid matches the network you intend to query
403/CORS errors in browser	Client-side call exposing key	Proxy the request through a backend

---

Configuring your API Key on AVXTO Wallet

Now it’s time to add your Etherscan key to AVXTO Wallet so it can load BNB data from Etherscan.

Wait for the banner to warn you that BNB chain could not be loaded. Find the add key link after the message:

Enter the key and click Save. You should now be good to go!

Conclusion

Configuring an Etherscan API key is a quick but essential step for any wallet, dashboard, or tool that needs to read on-chain data. The process boils down to three steps: create an account and generate a key, store that key securely as an environment variable rather than hardcoding it, and use it in your API requests with the correct chain ID and endpoint parameters. Following the security practices above — especially keeping the key server-side and out of version control — will keep your application and its users safe as you build out wallet functionality on top of Etherscan’s data.

There may be a time when you wish to securely sign a TX in an airgapped, offline setting and then broadcast it later. Or maybe prepare a TX and delay its execution until a certain time?

For this, AVXTO Wallet provides the TX Broadcast feature under the Toolbox menu.

On most transactional pages, select “sign only- don’t broadcast” and then copy the resulting Base64 encoded string

Then head over to the Toolbox menu and select Broadcast TX

And there you go! Simply choose the right chain and paste your Base64 TX into the text field. As soon as you hit send, the signed TX will be propagated on the Avalanche network, with sub-second finality!

The session password is a security feature which protects every bit of sensible data that is currently stored in your computer’s memory while using AVXTO Wallet.

When you enter your mnemonic phrase into AVXTO Wallet, it derives all the required secrets to allow you to move your funds. These include secret seeds, derived private keys, master Ethereum address key for C-Chain and so on.

The session password is used to encrypt all this data while it’s stored in memory. So, if a hacker somehow injects an exploit into your current browser session, they will only extract encrypted secrets from your computer memory.

This password is ephemeral and only used while you’re currently logged into your wallet. It is never stored anywhere and does not modify anything on-chain. It’s an exclusive AVXTO Wallet feature and not at all related to Avalanche. The password disappears once you log off. In fact, you can (and should) forget it and use a new session password the next time you log in.

Here’s the motivation for requiring this password and how it works.

Core App

When you use a wallet extension such as Core App, the private key is located in the browser extension and, the app itself, running in the web page, must request permission to sign every transaction.

There is a separation between the application and the component which signs transactions. It emulates how a hardware wallet would work. The browser extension is like a Ledger device which must be used to sign transactions requested by the web app.

This is a security feature. Even if the web page were compromised, a hacker would still need to compromise your browser to get access to the extension and then obtain the secret keys.

AVXTO Mnemonic Type Wallet

When using a mnemonic type wallet, the secrets would be stored in your computer memory inside the AVXTO Wallet web application itself. This is how the original Avalanche wallet worked.

At login time, the mnemonic phrase was processed to derive all the required secrets (approximately 10 pieces of sensible data), which were stored in variables inside a MnemonicWallet instance. All this is live in your current web browser’s memory. So if someone would dump the memory, or inject code into the wallet (using developer console for example), they would be able to extract the secrets.

AVXTO Wallet modifies this behavior by requesting you to enter a session password whenever you enter a mnemonic phrase. This password is processed using cryptographically secure functions to generate a key which encrypts all sensible data in your computer memory for as long as you’re using the wallet.

Signing Transactions

As a result of this encryption, you are requested to authorize transactions when using a mnemonic type wallet by entering your session password. (This was not required in the original Avalanche wallet, since the keys were all stored in memory in plain readable form, not encrypted.). Without the session password, the wallet cannot decrypt the secrets required to sign transactions. Which means that, your AVXTO Wallet session is unable to move funds on its own or by remote command. It requires one password entry per transaction or batch of transactions.

Batch and Long Running Transactions

Batch transactions, such as sending to multiple recipients, do not require one password entry per TX. This is a convenience feature meant to preserve the mnemonic wallet’s ease of use while still protecting your secrets.

Here’s how it works. When you start a batch transaction that involves more than one on-chain TX, the wallet prepares your batch all at once. For example, a cross-chain operation requires 2 transactions. AVXTO Wallet then prepares the 2 TX’s for you using the session password and then discards it.

That way if you use AVXTO Wallet’s multi send feature to pay 100 recipient addresses, you don’t have to sign 100 TX’s one by one.

Password Format

The session password can be anything. A single dot, a 4 number PIN, random letters, anything you can type into a text box. You can, and should, use a different random password every time you use the wallet. The whole idea is to protect in-memory data using a piece of information that an exploiter does not have access to. In other words, this password is only in your own memory, not the computer’s. It’s kinda like a 2FA just for a session.

Conclusion

The session password is an exclusive AVXTO Wallet feature that we included as abundance of caution. It’s technically not required an exploiting a wallet that doesn’t use it would be extremely hard. The original Avalanche wallet worked just fine for several years without this feature.

The password is never saved anywhere and does not remain in memory or on disk. It does not modify your wallet and is used exclusively during your present wallet session. It’s forgotten forever when you log out.

The tradeoff is that it requires you to enter a new password every time you start a transaction, otherwise the wallet does not have access to the secrets required to sign on-chain operations.

Unless you’ve been living in a cave for the past few days, you’ve probably heard about the ColdCard security issue. Being able to brute force cryptographic seeds from pseudo-random number generators is a classic security flaw which has plagued several projects in the past.

Let’s review, in very simple terms, what happened to Coldcard wallets.

ELI5 Coldcard Security Issue

When you create a new wallet, you’re actually just creating a huge new random number that, hopefully, has never been generated before.

In cryptographic terms, this random chunk of information is called entropy.

Entropy is broken into smaller chunks, each of which is then mapped to a dictionary word. This word sequence is what we know as a mnemonic phrase. Thus your mnemonic is simply a way to encode the wallet seed which gives you access to the master private key which, in turn, allows you to transfer funds.

What happens if the entropy generation step was reproducible? Given the right starting point, you could then generate the same mnemonic again. Which, as you may have already guessed, would compromise the wallet. Seeds and keys are infinite and very hard to guess, but starting points are not. That is is where the flaw lies.

If you have a deterministic pseudo-number generator that always recreates the same sequence of numbers if you start from the same point, then all we have to do to hack this wallet is guess the starting point.

Some projects have even used the time of day as a starting point. This is the most classic mistake in cryptographic systems and can be guessed in 86400 tries (the number of seconds in a day) which is trivial for any size computer.

Guessing the starting point is what Coldcard wallet hackers did. Instead of guessing 256 bits from the keys, they only had to guess 40 bits, which though still a huge number, is a tractable problem given good hardware and skills. So much so, the hackers have been pretty successful, draining thousands of Bitcoin as of this writing.

The exploiters found that Coldcard was using a deterministic system which you could play back and generate the same mnemonic as the wallet owner did. When a valid mnemonic was found, the hackers obtained access to the exact same wallet as the coldcard, except remotely.

How does AVXTO Wallet generate mnemonics?

AVXTO Wallet runs in your web browser. Modern browsers provide a cryptographic API which AVXTO Wallet uses to generate the huge chunk of random data you need for a mnemonic.

AVXTO Wallet calls the web browser’s Window.crypto interface via the bip39.generateMnemonic library call.

generateMnemonic may be provided with a random number generator via its 2nd parameter. When not provided, it falls back to using @noble/hashes utility randomBytes method, as implemented below :

export function randomBytes(bytesLength = 32): TRet<Uint8Array> {
  // Match the repo's other length-taking helpers instead of relying on Uint8Array coercion.
  anumber(bytesLength, 'bytesLength');
  const cr = typeof globalThis === 'object' ? (globalThis as any).crypto : null;
  if (typeof cr?.getRandomValues !== 'function')
    throw new Error('crypto.getRandomValues must be defined');
  // Web Cryptography API Level 2 §10.1.1:
  // if `byteLength > 65536`, throw `QuotaExceededError`.
  // Keep the guard explicit so callers can see the quota in code
  // instead of discovering it by reading the spec or host errors.
  // This wrapper surfaces the same quota as a stable library RangeError.
  if (bytesLength > 65536)
    throw new RangeError(`"bytesLength" expected <= 65536, got ${bytesLength}`);
  return cr.getRandomValues(new Uint8Array(bytesLength));
}

As you can see, it uses the web browser’s window.crypto interface.

How secure is AVXTO Wallet’s crypto interface?

The answer is:

AVXTO Wallet is as secure as your web browser is.

Since AVXTO is interpreted by your web browser, it can only be as secure as the browser implementation.

When we request random bytes from the window.crypto API we are assuming it is cryptographically secure, as documented in the API.

What if the underlying web browser is compromised? Then there is nothing we can do to protect you. The web browser is the engine on which AVXTO Wallet runs. The wallet application cannot see into the web browser, it assumes you’re running a clean, secure browser session.

How do I secure my web browser?

There are several things you can do to harden your web browser for cryptocurrency usage. These are general tips, not specific to AVXTO Wallet.

Remember, any wallet that runs on your web browser has a similar security constraint. Your Solana or Ethereum wallet extensions all depend on a clean browser to be secure as well.

First of all, use a clean profile for cryptocurrency. If you use the web browser for work and entertainment under profile A, create a new, clean, profile for crypto and run it separately from profile A. There are online instructions on how to do this for most popular browsers. Search for “how to create new Chrome profile” or ask your AI for instructions.

For example, in a Windows CMD terminal you could use this:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="Crypto Profile 1"

That would run a new Chrome instance under “Crypto Profile 1”, which would be separate from your default Chrome profile.

Also, on your crypto profile, never install any other extensions except for your crypto wallets. Better still if you can separate cryptocurrencies. E.g. one profile for Avalanche, another for Metamask, another for Solana. That way you don’t keep all your eggs in a single basked in case one of them is compromised.

Keep your antivirus up to date. Just like AVXTO Wallet depends on your browser. The browser itself depends on your operating system. If your OS is compromised, then so is your browser and so is your wallet.

Lastly, if possible, use a Linux or Macos computer for your crypto work. Linux recommended.

Conclusion

Security is all about building a chain of trust. Just like a blockchain only guarantees that a block is valid if all other blocks before it are valid as well, same thing applies to your computer.

It’s a chain of trust. Your computer is only as secure as the environment it’s placed it. Your OS is only as secure as the computer it’s running on. The web browser is only as secure as the OS it’s installed in. And lastly, AVXTO Wallet is only as secure as your web browser. By keeping all these components safe, you’re doing your part in keeping your crypto safe as well.

AVXTO Wallet is built to be as secure as possible, but there is nothing we can do if the underlying system is compromised.

First of all, choose a tried and tested web browser. If everyone is using Chrome, then go with Chrome. We know Chrome’s crypto implementation is good, since millions of people use it daily and very few wallets get drained (perhaps for different reasons, out of the browser’s control).

Always use a clean, secure, web browser profile for cryptocurrency work. Access your new browser profile, work your crypto, then close it. Never use your crypto browser profile for anything else. Your gaming/browsing/work profile may contain extensions that can access your crypto extension’s data. Never mix extensions. Your crypto work profile should only contain one extension, which in our case is Core App.

Advanced users manage huge amounts of crypto using their web browsers without any issues. By following a few good practices, and common sense, you can be as secure as any professional user.

We’ve recently added network rate limiting to AVXTO Wallet

Some operations, especially in older wallets with lots of derived addresses, ended up overwhelming the public API endpoints, which start to respond with 429 Too Many Requests errors.

As good netizens, we decided to limit the amount of requests made by AVXTO Wallet

What does this mean for your?

It probably means you need to be patient if the wallet hangs or the spinner wait screens seem to be taking a little longer than usual.

Cross-chain recovery functions on the Advanced page are especially prone to making a lot of network requests while searching for your missing UTXOs to import. Be patient and it will eventually finish, while avoiding network blocks by the API and RPC endpoints.

Your balance may also not immediately update after recent transactions. If you’re in a big hurry, then use a newer wallet with fewer transactions and addresses in its history. The older the wallet, the slower it is.

Occasional bursts are ok. Maybe you need to solve something quick, close the wallet and get on with your life. In those cases, you can go to the Config page and reduce or turn network rate limiting altogether. API and RPC endpoints can take bursts, but not continuous 24×7 request flooding.

For most regular usage we recommend you set the timeouts higher. You probably don’t need your wallet checking address balances and updating your tokens every 30 seconds. If this is a cold wallet you don’t access often, you can set the maximum requests to a really low threshold.

Setting sensible limits will save resources for everyone and guarantee your IP isn’t blocked.

API endpoints may block your IP range indefinitely if you set the network requests to a low timeout. We see such complaints all the time in support forums. So to avoid getting your IP blocked, be conscious of your network resource usage.

Also, when not using the wallet, please close the browser window. AVXTO Wallet needs to make a lot of background requests toe the API and RPC endpoints in order to stay in sync with the Avalanche network. For example, it gets the latest blocks for C, X and P chains all the time, it checks your tokens balances for all your derived addresses and so on. So make sure you close all wallet windows when you leave, as to save network resources for everyone else. (And to protect you from IP blocks.)

What to do if you get blocked

If you get a red alert status message saying you have been blocked, then your only option is to close AVXTO Wallet and wait it out. Hopefully it was just an automated API gateway rate limiting device and not a manual block.

For permanent manual blocks, you either can reboot your modem and hope you land on a new IP block or you can sign up for VPN access and switch your network location. It’s best to avoid getting blocked by using a sensible configuration that doesn’t overwhelm the network resources.

Avalanche Wallet, which AVXTO Wallet later forked, was originally designed by Ava Labs to be used with mnemonic, ledger, xpub and private key wallets.

We extended it to use Core App Extension, which is currently the official Avalanche wallet solution.

But, as you may expect, there are a few differences between the two, mainly regarding HD wallets. Here’s what you should know.

HD Wallets

HD wallets are able to derive new addresses from your master key. These wallets are privacy oriented and may even protect you from quantum cryptanalysis in the future!

You can find a complete intro to HD wallets on the WWW or from your favorite AI chat, but here’s a few tidbits you should know about AVXTO Wallet and HD wallets.

tl;dr; Core App extension isn’t really designed to use HD wallets with derived addresses.

Now for the longer version...

Balances

Core App Extension checks balances up to a certain number of derived addresses, then it stops. It was originally designed to use a single address, but then older wallets from the original Avalanche Wallet era would display and incorrect balance. Thus, they made it so Core can read a few derived addresses, but not an infinite number like AVXTO Wallet can.

This means your balance from, say, address index 211 in AVXTO Wallet, may not actually show up on Core App! This is usually OK if you still have your mnemonic key, since mnemonic wallets in AVXTO Wallet are able to scan down to infinite keys (though that’d make it really really slow and you’d be hammering the API endpoints with tons of requests).

Therefore if you use HD wallets extensively in AVXTO Wallet, your mnemonic wallet and Core App balance may not match exactly. This doesn’t mean your funds are lost. Just means Core Extension can’t reach that address index.

Cross Chain TXs

Here’s where we found most problems during development and testing.

When you perform a cross-chain transfer, AVXTO Wallet used to be designed to use as far as possible an address for the destination funds. This broke down on our 3rd or 4th test, because AVXTO Wallet jumped to an index Core App could no longer reach.

The Core Extension on the sidebar would show one balance and AVXTO Wallet would show another.

We made a tough decision here. (We had to.)

Cross chain transfers will always send funds to the very first address in your wallet. The one Core App shows you by default. We had to do it to maintain compatibility. But this doesn’t have to compromise your privacy or security.

After the crosschain TX is done, there’s nothing stopping you from moving it to a new X chain address from your address list! As long as you’re using a mnemonic wallet, you’ll be able to reach any address index you want.

Core App, on the other hand, will restrict you to a certain amount of initial addresses. At the time of this writing it was approximately 50 or something like that. Don’t count on this number at all. They may restrict it to 1 address if they want to.

So, if you want Core App compatibility, always use the very first address. The one Core App shows you.

Conclusion

A mnemonic AVXTO Wallet can reach any address Core App shows you, but Core App cannot reach every AVXTO Wallet address. We had to make some compromises here to maintain compatibility with Core Extension and Core App.

If your funds aren’t showing up identically on Core and AVXTO Wallet, it probably means you used a far away, high index HD wallet derived address.

To derive an address, AVXTO Wallet had to have your master private or xpub key available. So, if you didn’t mess your keys up, your funds should be safe, as long as you can reach its private key to sign TXs with.

HD wallets can derive almost an infinite number of keys, so you should be able to reach your funds no matter where you placed them down the HD hierarchy. Just keep in mind that Core App won’t always show all your address balances and most importantly, it won’t be able to sign any index, it’s designed to use the very first derived key only. It searches a bit forward for convenience and for compatibility with older wallets, but they may get rid of HD entirely at any time.

When using Core App with AVXTO Wallet you’re probably better off just using the default address shown on Core App. It’s the 0 (zero) index HD wallet address on AVXTO Wallet. For more adventurous transactions, use the mnemonic wallet type.

You can always view your derived HD addresses on AVXTO Wallet’s “Addresses” page via the sidebar menu or using the AVXTO Wallet derivation tool.

Read our Quick Start guide to get started in the AVXTO Ecosystem!