Etherscan: Avslør Scam-Kontrakter i 12 Steg [2026]

Du har akkurat limt inn en ukjent kontraktadresse i MetaMask, og fingeren svever over “Godkjenn”-knappen. Et nytt token lover 40 prosent avkastning i uken, en venn har delt en lenke til en angivelig “revidert” DeFi-protokoll, eller du prøver å finne ut hvor pengene tok veien etter at en lommebok ble tømt i natt. I alle disse situasjonene finnes det ett verktøy nesten alle i Ethereum-miljøet bruker, men som svært få faktisk kan lese godt: Etherscan.

Etherscan er gratis, offentlig tilgjengelig, og viser i teorien alt som skjer på kjeden. Problemet er at rådataene er uoversiktlige for de fleste, og at et “Verified”-merke på en kontrakt lett tolkes som et trygghetsstempel det aldri var ment å være. Etherscan opplyste selv, ifølge en sak hos nyhetstjenesten Weex i mars 2026, at Ethereum-økosystemet så rundt 17 millioner rug pull-forsøk mellom 2022 og 2024, som rammet 1,3 millioner brukere og kostet minst 79,3 millioner dollar. Samme kilde pekte på at adresseforgiftning (address poisoning) økte med 612 prosent etter Fusaka-oppgraderingen 3. desember 2025.

Denne artikkelen viser deg, steg for steg, hvordan du bruker Etherscan og den nye API V2 til å verifisere en smartkontrakt før du signerer noe, avsløre honeypot-token, sjekke hvilke fullmakter lommeboken din allerede har gitt bort, og spore stjålne midler etter et hack. Du bygger også et lite Node.js-skript som automatiserer de kjedeligste sjekkene, slik at du slipper å gjøre alt manuelt hver gang.

Guiden er skrevet for to typer lesere. Den første er deg som bare vil sjekke et nytt token før du kjøper, og klarer deg fint med nettsiden og ti minutter per sjekk. Den andre er deg som følger flere lommebøker eller protokoller samtidig, og vil ha et skript som gjør det tunge arbeidet automatisk. Følg stegene i rekkefølge uansett hvilken av de to du er, siden skript-delen bygger direkte på begrepene fra de manuelle stegene.

Hva er Etherscan og hvorfor API V2 betyr noe i 2026

Etherscan er den mest brukte blokkutforskeren for Ethereum og flere andre EVM-kompatible kjeder. Fram til 2025 krevde hver kjede sin egen nettside og sin egen API-nøkkel: Etherscan for Ethereum, BscScan for BNB Chain, Basescan for Base, og så videre. Det endret seg med API V2, som samler alt bak én base-URL (api.etherscan.io/v2/api) og lar deg velge kjede med parameteren chainid. Ifølge Etherscans egen dokumentasjon dekker én V2-nøkkel i dag over 50 kjeder, og de gamle V1-endepunktene ble, ifølge selskapets migreringsnotat, faset ut 15. august 2025.

Endringen betyr i praksis at et skript du skriver for å sjekke en kontrakt på Ethereum (chainid=1) fungerer nesten identisk på Base, Arbitrum eller andre kjeder Etherscan støtter, bare ved å bytte ett enkelt tall. Det gjør det verdt å lære verktøyet skikkelig, siden kunnskapen gjenbrukes på tvers av det meste av Ethereum-økosystemet du sannsynligvis allerede bruker.

Gratisnivået er fortsatt nyttig for enkeltbrukere, men har klare grenser. Tabellen under viser kapasiteten per plan slik Etherscan selv lister den.

Plan	Kall per sekund	Kall per dag	Passer til
Free	3	100 000	Enkeltbrukere, manuelle sjekker
Lite	5	100 000	Små personlige skript
Standard	10	200 000	Jevnlig overvåking av få adresser
Advanced	20	500 000	Flere adresser, hyppigere polling
Professional	30	1 000 000	Produksjonsnære overvåkingstjenester
Pro Plus	30	1 500 000	Høyvolum, flerkjede-drift

Nøyaktige priser på de betalte nivåene endrer seg jevnlig, så sjekk alltid gjeldende tall direkte på Etherscans nettsted før du binder deg til et abonnement. En oversikt over blokkutforskere publisert av eco.com i 2026 satte laveste betalte nivå (Lite) til rundt 49 dollar i måneden på det tidspunktet artikkelen ble skrevet. For en vanlig bruker som sjekker noen få kontrakter i uken er gratisnivået mer enn nok. Bygger du et automatisk overvåkingsskript som poller flere adresser kontinuerlig, som vi gjør senere i denne artikkelen, bør du planlegge for et betalt nivå eller legge inn streng kø-styring i koden.

Etherscan versus andre utforskere

Etherscan er ikke det eneste alternativet. Blockscout er et åpen kildekode-alternativ som flere layer 2-nettverk kjører i egen regi, og har ifølge eco.coms utviklerguide fra 2026 beveget seg mot et API-format som ligner Etherscans eget, blant annet for å gjøre det enklere å migrere skript mellom de to. Fordelen med Etherscan er dekningen: på grunn av V2-migreringen kan du i praksis bruke samme nøkkel og samme kallmønster på de fleste store EVM-kjeder, mens Blockscout-instanser ofte er knyttet til én spesifikk kjede eller ett spesifikt nettverk. Lærer du deg Etherscans API-mønster først, overfører du kunnskapen lett til alternativene senere, om du skulle få bruk for det.

Forutsetninger: dette trenger du før du starter

Sørg for at du har følgende klart før du går videre:

En nettleser og en gratis Etherscan-konto (etherscan.io/register)
Node.js 20 LTS eller nyere installert, til skript-delen av guiden
curl eller et tilsvarende verktøy for å teste API-kall direkte fra terminalen
En smartkontrakt-adresse du vil undersøke (bytt ut plassholderadressene i eksemplene med din egen)
Grunnleggende kjennskap til hvordan Ethereum-transaksjoner og ERC-20-tokens fungerer
Rundt 45 minutter sammenhengende tid, pluss litt ekstra om du også bygger varslingsskriptet i steg 11

Du trenger ikke programmeringserfaring for å følge steg 1 til 8. Steg 9 til 11 bruker Node.js og krever at du er komfortabel med å kjøre kommandoer i et terminalvindu.

Steg 1: Opprett Etherscan-konto og API-nøkkel

Gå til etherscan.io og opprett en gratis konto. Etter innlogging finner du “API Keys” under kontomenyen. Klikk “Add”, og gi nøkkelen et beskrivende navn, for eksempel “kontraktsjekk-prosjekt”. Nøkkelen genereres umiddelbart og er knyttet til kontoen din, ikke til én bestemt kjede, siden V2 deler samme nøkkel på tvers av alle støttede nettverk.

Siden en V2-nøkkel er knyttet til hele kontoen og fungerer på alle kjeder, bør du behandle den med samme forsiktighet som et passord. Mister du kontroll over nøkkelen, kan den i prinsippet brukes til å gjøre et stort antall kall i ditt navn og bruke opp dagskvoten din, selv om den ikke gir noen direkte tilgang til midlene dine. Lagre nøkkelen i en .env-fil lokalt, aldri direkte i kildekoden og aldri i en offentlig GitHub-repo. Et typisk oppsett ser slik ut:

ETHERSCAN_API_KEY=din_etherscan_nokkel

Test at nøkkelen fungerer med et enkelt API-kall fra terminalen:

curl "https://api.etherscan.io/v2/api?chainid=1&module=stats&action=ethsupply&apikey=DIN_API_NOKKEL"

Får du et JSON-svar med “status”:”1″ tilbake, er nøkkelen aktiv og klar til bruk.

Steg 2: Finn riktig kontraktadresse

Dette høres opplagt ut, men er den vanligste kilden til feil blant nybegynnere. Kopier alltid kontraktadressen direkte fra en kilde du stoler på, prosjektets offisielle nettside, et verifisert innlegg fra teamet, eller direkte fra lommebokens egen transaksjonshistorikk. Aldri fra en kommentar, en Telegram-melding eller et søkeresultat du ikke har dobbeltsjekket.

Lim adressen inn i søkefeltet øverst på etherscan.io. Se nøye på navnet og eventuelle merker Etherscan viser, men stol ikke blindt på dem ennå. Det er nettopp det de neste stegene handler om å teste. Noter deg spesielt om Etherscan merker adressen med en advarsel, for eksempel en rød scam- eller phishing-merking, siden fellesskapet rapporterer inn kjente svindeladresser fortløpende.

Se også på “Contract Creator”-feltet og datoen kontrakten ble deployet. En kontrakt opprettet for noen timer siden, av en lommebok som selv ble finansiert for noen timer siden, har ingen omdømme å tape, og bør vurderes annerledes enn en kontrakt med måneder eller år med historikk bak seg. Dette er ikke en garanti i seg selv, men ett av mange små signaler som bygger opp det samlede risikobildet.

Steg 3: Sjekk om kildekoden er verifisert

Klikk på fanen “Contract” på kontraktsiden. Der ser du umiddelbart om kildekoden er verifisert. Er den det, kan du lese Solidity-koden direkte i nettleseren. Er den ikke det, bør det alene gjøre deg mistenksom, siden et legitimt prosjekt normalt ikke har noen grunn til å skjule koden sin.

Du kan hente samme informasjon programmatisk via API-et, noe som blir nyttig når du automatiserer sjekken lenger ned i artikkelen:

curl "https://api.etherscan.io/v2/api?chainid=1&module=contract&action=getsourcecode&address=0xKONTRAKTADRESSE&apikey=DIN_API_NOKKEL"

Et vellykket svar inneholder felter som ContractName, CompilerVersion, OptimizationUsed, ConstructorArguments, og, viktigst for neste steg, Proxy og Implementation. Er SourceCode-feltet tomt, regner du kontrakten som uverifisert, uansett hva nettsiden viser deg visuelt. Et forenklet eksempel på et vellykket svar ser slik ut:

{
  "status": "1",
  "message": "OK",
  "result": [
    {
      "ContractName": "ExampleToken",
      "CompilerVersion": "v0.8.19+commit.7dd6d404",
      "OptimizationUsed": "1",
      "SourceCode": "pragma solidity ^0.8.19; contract ExampleToken { ... }",
      "Proxy": "0",
      "Implementation": ""
    }
  ]
}

Legg merke til at Proxy her er “0”, altså ikke en proxy-kontrakt, og at Implementation derfor er tom. Ser du i stedet Proxy=”1″ og en utfylt Implementation-adresse, vet du at du må gå videre til neste steg før du vurderer koden som ferdig lest.

Husk at verifisert kildekode kun betyr at den innsendte koden samsvarer med det som faktisk er deployet. Det er ikke en revisjon, og det er ingen garanti for at koden er trygg. En useriøs utvikler kan verifisere kode som helt åpent inneholder bakdører, rett og slett fordi svært få brukere faktisk leser gjennom dem linje for linje.

Steg 4: Avslør proxy-kontrakter og skjult logikk

Mange moderne kontrakter bruker et proxy-mønster for å kunne oppgraderes etter utrulling. Det er ikke i seg selv et faresignal. Store protokoller som Uniswap og Aave bruker det av gode grunner. Men det betyr at logikken du samhandler med kan endres av noen andre enn deg, når som helst.

Sjekk Proxy-feltet i API-svaret fra forrige steg, eller se etter fanene “Read as Proxy” og “Write as Proxy” på nettsiden. Finner du disse, må du lese implementasjonskontraktens kode, ikke bare proxy-skallet, siden det er der den faktiske funksjonaliteten ligger. Spør deg selv hvem som kontrollerer admin-nøkkelen som kan bytte implementasjon. Er det en multisig med kjente adresser, eller en enkelt lommebok uten historikk?

En kontrakt som er proxy-basert og samtidig har en admin-adresse opprettet for få dager siden, uten tidligere transaksjonshistorikk, er en kombinasjon som fortjener ekstra skepsis før du låser inn midler.

Sjekk også “Events”-fanen på implementasjonsadressen for tidligere Upgraded-hendelser. Et proxy-mønster som har byttet implementasjon flere ganger de siste ukene antyder enten et team som fortsatt jobber aktivt med koden, eller et prosjekt som endrer reglene oftere enn du ønsker å følge med på. Begge tolkningene er verdt å ha i bakhodet før du binder opp midler i kontrakten over tid.

Steg 5: Les koden for honeypot-signaler

Honeypot-token er konstruert slik at du kan kjøpe, men ikke selge, eller slik at bare utvalgte adresser, ofte utviklerens egne, slipper gjennom salgsfunksjonen. Du trenger ikke være Solidity-ekspert for å kjenne igjen de vanligste mønstrene. Bruk søkefunksjonen i kodevisningen på Etherscan og let etter navnene i tabellen under.

Signal i koden	Hva det gjør	Hvorfor det er risikabelt
Owner-kontrollert mint	Lar eieren lage nye token fritt	Kan utvanne eller tømme verdien når som helst
blacklist / setBlackList	Blokkerer bestemte adresser fra å selge	Brukes ofte til å sperre inne vanlige kjøpere
setTrading / handel av/på	Lar eieren skru salg helt av	Kan stoppe alle salg samtidig, bortsett fra eierens egne
Asymmetrisk avgift	Ulik avgift på kjøp og salg	Salg kan koste 50-99 prosent i gebyr
Endrbar maks-lommebok-grense	Begrenser hvor mye én adresse kan holde	Grensen kan justeres etter lansering uten varsel
Delegatecall i transfer-funksjonen	Henter logikk fra en annen kontrakt ved overføring	Skjuler reell oppførsel bak et ekstra lag
Skjult upgrade-admin	En adresse kan bytte kontraktlogikk	Hele kontraktens virkemåte kan endres senere

Funksjonsnavn alene er ikke endelig bevis. En ærlig kontrakt kan ha en pause-funksjon av helt legitime grunner under en migrering. Kombinasjonen av flere signaler, og hvem som faktisk kontrollerer dem, er det som forteller deg noe reelt.

Slik ser et honeypot-mønster ut i praksis

Et typisk forløp starter med at token-prisen stiger jevnt de første timene etter lansering, ofte drevet av kjøp fra flere separate adresser som i realiteten kontrolleres av samme person. Når noen utenfor denne gruppen prøver å selge, reverteres transaksjonen, eller den går gjennom med et gebyr på 90 prosent eller mer. På Etherscan ser du dette igjen som en lang liste med vellykkede kjøp og svært få, eller ingen, vellykkede salg fra andre adresser enn de første kjøperne. Sorter transaksjonslisten etter type, og sjekk om “Failed”-transaksjoner hoper seg opp rundt salgsfunksjonen spesifikt. Det er sjeldent et godt tegn.

Steg 6: Sjekk eierskap og “renounced ownership”-fellen

Mange svindeltoken fjerner mistanke ved å vise “Renounced” i eierskapsfeltet, altså at eier-adressen er satt til null. Problemet er at dette ofte selger en falsk trygghet, og useriøse team vet godt at mange kjøpere stopper undersøkelsen akkurat der. Kontroll kan fortsatt ligge i en proxy-admin, en egen rollebasert tilgangskontroll, en ekstern manager-kontrakt, eller en mint-funksjon som aldri var bundet til owner-variabelen i utgangspunktet.

Sjekk derfor alltid: Finnes det roller utover owner i koden? Er det en egen admin for proxy-kontrakten, atskilt fra selve token-eierskapet? Har noen av disse adressene gjort privilegerte transaksjoner nylig, som å endre en grense eller trekke ut likviditet? Svaret finner du under fanene “Internal Txns” og “Events” på kontraktsiden.

Kontrakter bygget med rammeverk som OpenZeppelins AccessControl bruker ofte flere navngitte roller, for eksempel MINTER_ROLE eller PAUSER_ROLE, i stedet for en enkelt owner-variabel. Søk i kildekoden etter “ROLE” og “grantRole” for å se hvem som faktisk kan utføre de mest kraftfulle handlingene. En kontrakt kan godt vise “Renounced” på selve owner-feltet, samtidig som en helt annen adresse fortsatt har MINTER_ROLE og kan lage nye token i det uendelige. Det er dette gapet useriøse prosjekter regner med at du ikke sjekker.

Steg 7: Analyser holderfordelingen

Åpne Holders-fanen på token-siden. Se bort fra brenningsadresser, kjente likviditetspooler, broer og børslommebøker, disse forvrenger bildet uten å representere reell konsentrasjonsrisiko. Det som gjenstår, og hvor stor andel av tilbudet disse adressene kontrollerer, er det reelle risikobildet.

Er 60-70 prosent av sirkulerende tilbud samlet på tre til fire adresser uten åpenbar forklaring, som en revisjonsfirma-multisig eller en dokumentert vesting-kontrakt, er det en sterk indikator på at prisen kan styres, eller at et rug pull kan skje idet disse adressene selger samtidig.

Merk at Etherscans offentlige API ikke alltid eksponerer en ferdig prosentvis holderliste på gratisnivået for alle tokens. For de grundigste sjekkene må du derfor ofte kombinere nettsidens Holders-fane med manuell lesing av de største transaksjonene.

Se også på hvor nye de store holder-adressene er. En vesting-kontrakt fra et seriøst team har vanligvis en lang historikk og en forutsigbar, offentlig kjent frigivelsesplan, mens en adresse som ble opprettet samme uke som token-lanseringen og allerede sitter på en tredjedel av tilbudet, bør vurderes som en betydelig risiko uansett hva prosjektets egne kanaler hevder.

Steg 8: Sjekk token-godkjenninger (approvals)

En godkjenning, eller approval, er en fullmakt du gir en kontrakt til å flytte tokens på dine vegne. Den vanligste måten lommebøker faktisk blir tømt på, er at offeret selv signerte en bred fullmakt uker eller måneder tidligere, lenge før selve tyveriet skjedde. Før du samhandler med en ny kontrakt, sjekk hvilke fullmakter lommeboken din allerede har stående.

curl "https://api.etherscan.io/v2/api?chainid=1&module=account&action=tokenapproval&address=0xDIN_LOMMEBOK&page=1&offset=100&apikey=DIN_API_NOKKEL"

Gjennomgå resultatet og se etter fullmakter til adresser du ikke kjenner igjen, spesielt de med ubegrenset beløp, ofte vist som et svært stort tall nær maksimal uint256-verdi. Gjør det til en vane å trekke tilbake fullmakter du ikke lenger bruker aktivt. Et utdrag av et typisk svar kan se slik ut, med spender-adressen som fikk fullmakten og beløpet den gjelder for:

{
  "status": "1",
  "result": [
    {
      "tokenName": "ExampleToken",
      "spender": "0xSPENDER_ADRESSE",
      "value": "115792089237316195423570985008687907853269984665640564039457584007913129639935",
      "blockNumber": "21345678"
    }
  ]
}

Det lange tallet i value-feltet er det maksimale uint256-tallet, altså en fullmakt uten praktisk øvre grense. Finner du en slik fullmakt til en spender du ikke lenger kjenner igjen eller bruker, bør du trekke den tilbake direkte fra lommebokens grensesnitt eller et dedikert revokasjonsverktøy.

Steg 9: Bygg et automatisk sjekk-skript med Node.js

Manuell sjekking fungerer fint for en enkeltstående kontrakt, men blir fort tungvint om du vurderer flere token i uken. Her bygger vi et lite kommandolinje-skript som kombinerer verifiseringssjekk og proxy-deteksjon i ett kall. Tanken er ikke å erstatte stegene du allerede har lært, men å gjøre de to raskeste, mest repeterbare sjekkene, verifisering og proxy-status, til noe du kan kjøre på sekunder i stedet for å klikke deg gjennom nettsiden hver gang.

Opprett en mappe, initialiser prosjektet og installer avhengigheter:

mkdir contract-check && cd contract-check
npm init -y
npm install dotenv node-fetch

Opprett filen contract-check.js med følgende innhold:

require('dotenv').config();
const fetch = require('node-fetch');

const API_KEY = process.env.ETHERSCAN_API_KEY;
const BASE_URL = 'https://api.etherscan.io/v2/api';
const CHAIN_ID = 1;

async function checkContract(address) {
  const url = `${BASE_URL}?chainid=${CHAIN_ID}&module=contract&action=getsourcecode&address=${address}&apikey=${API_KEY}`;
  const res = await fetch(url);
  const data = await res.json();
  const result = data.result[0];

  const verified = Boolean(result.SourceCode && result.SourceCode.length > 0);
  const isProxy = result.Proxy === '1';

  console.log(`Kontrakt: ${address}`);
  console.log(`Verifisert: ${verified ? 'Ja' : 'Nei'}`);
  console.log(`Proxy: ${isProxy ? 'Ja (implementasjon: ' + result.Implementation + ')' : 'Nei'}`);
  console.log(`Kompilator: ${result.CompilerVersion || 'Ukjent'}`);

  if (!verified) {
    console.log('ADVARSEL: Uverifisert kildekode. Vurder å ikke samhandle med kontrakten.');
  }
}

const target = process.argv[2];
if (!target) {
  console.error('Bruk: node contract-check.js 0xKONTRAKTADRESSE');
  process.exit(1);
}

checkContract(target).catch(console.error);

Kjør skriptet med en reell adresse for å se det i aksjon:

$ node contract-check.js 0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984
Kontrakt: 0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984
Verifisert: Ja
Proxy: Nei
Kompilator: v0.5.16+commit.9c3226ce

Steg 10: Spor stjålne midler etter et hack

Blir en lommebok tømt, er de første minuttene avgjørende for å forstå omfanget, selv om midlene sjelden lar seg stoppe i etterkant uten sentralisert hjelp. Start med den mistenkelige transaksjonen på Etherscan og åpne fanene “Internal Txns” og “Token Transfers” under den. Noter mottakeradressen, og følg samme prosess videre derfra, hopp for hopp.

For ERC-20-token må du følge token-overføringshistorikken spesifikt, ikke bare native ETH-bevegelser, siden mye verdi flyttes som tokens. Inspiser også interne kall og hendelseslogger når midlene passerer gjennom andre kontrakter, som DEX-rutere eller tjenester som i praksis fungerer som miksere.

Vær realistisk om begrensningene. Etherscan er et utforskningsverktøy, ikke et komplett etterforskningssystem. Midler som går gjennom miksere, krysser til andre kjeder via broer, eller settes inn på en sentralisert børs, bryter den enkle adressesporingen. Adresseforgiftning, der angripere sender småbeløp fra adresser som ligner på dine egne tidligere mottakere, gjør det ekstra lett å kopiere feil adresse ved et uhell, et problem Etherscan selv omtalte som økende etter Fusaka-oppgraderingen i desember 2025.

Dokumenter hver adresse og transaksjonshash du finner underveis. Dette er informasjonen du trenger dersom du vurderer å kontakte en børs, politiet, eller et sporingsselskap for videre oppfølging.

Når sporet stopper: miksere, broer og børser

Vær forberedt på at sporet ofte tar slutt lenge før du finner en identifiserbar person. Krysser midlene til en annen kjede via en bro, må du åpne et separat utforskerverktøy for målkjeden og fortsette sporingen der, siden Etherscan kun viser Ethereum-siden av overføringen. Lander midlene på en sentralisert børs, kan selve børsen i teorien identifisere mottakeren internt, men vil normalt bare dele den informasjonen med politiet etter en formell anmeldelse, ikke med en enkeltperson som spør direkte. Går midlene gjennom en tjeneste som blander sammen mange brukeres innskudd før utbetaling, blir den videre sporingen i praksis umulig med Etherscan alene, og krever spesialiserte kjedeanalyse-verktøy som kombinerer flere datakilder.

Steg 11: Sett opp sanntidsvarsling

Utvid skriptet fra steg 9 slik at det varsler deg automatisk, for eksempel via en Telegram-bot, når en overvåket adresse mottar en ny, stor token-godkjenning eller en uventet overføring.

async function sendAlert(message) {
  await fetch(`https://api.telegram.org/bot${process.env.TG_BOT_TOKEN}/sendMessage`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      chat_id: process.env.TG_CHAT_ID,
      text: message
    })
  });
}

async function watchApprovals(wallet) {
  const url = `${BASE_URL}?chainid=${CHAIN_ID}&module=account&action=tokenapproval&address=${wallet}&page=1&offset=20&apikey=${API_KEY}`;
  const res = await fetch(url);
  const data = await res.json();
  const latest = data.result[0];
  if (latest && isNewApproval(latest)) {
    await sendAlert(`Ny token-godkjenning oppdaget: https://etherscan.io/tx/${latest.hash}`);
  }
}

Opprett en bot via BotFather i Telegram, hent token-nøkkelen den gir deg, og legg den i .env-filen sammen med API-nøkkelen fra Etherscan. Kjør skriptet som en enkel cron-jobb, eller la det kjøre kontinuerlig i et terminalvindu med en kort pause mellom hvert kall, for å holde deg innenfor ratebegrensningen på kontoen din. Funksjonen isNewApproval i eksempelet er bevisst utelatt her, siden den enkleste versjonen bare sammenligner den nyeste transaksjonshashen med den forrige kjøringen, lagret i en liten lokal fil, og varsler deg hvis den har endret seg siden forrige sjekk.

Steg 12: Kryssjekk før du signerer noe som helst

Det siste steget er en vane, ikke en enkeltstående handling. Før du signerer noe mot en ny kontrakt, kjør gjennom en kort sjekkliste: er koden verifisert, er det en proxy, hvem kontrollerer admin-rollen, hva sier holderfordelingen, og hvilken fullmakt ber transaksjonen faktisk om?

Vær spesielt oppmerksom på en nyere risiko fra Ethereums Pectra-oppgradering i mai 2025, autorisasjonsmekanismen kjent som EIP-7702. Den lar en vanlig lommebok midlertidig oppføre seg som en smartkontrakt. Ifølge Ethereums offisielle dokumentasjon kan en bruker som uvitende delegerer kontoen sin til en ondsinnet kontrakt, miste kontrollen fullstendig, siden angriperen i praksis får samme makt som om de hadde privatnøkkelen selv. Utviklerdokumentasjonen til lommebok-infrastrukturen Pimlico beskriver det treffende: å godkjenne en slik delegering krever samme grad av tillit som å overlevere selve privatnøkkelen din. Selv etter en delegering kan den opprinnelige privatnøkkelen fortsatt signere transaksjoner og endre delegeringen videre, ifølge dokumentasjonen til lommebok-standarden Safe, så en tidligere delegering fjerner ikke behovet for å beskytte nøkkelen din videre.

Bruk Etherscan til å se om en adresse du samhandler med har en aktiv kode-delegering, synlig som en kontraktlignende oppføring på en adresse som egentlig er en vanlig lommebok, før du godkjenner noe lommeboken din foreslår.

Vanlige fallgruver når du bruker Etherscan

De fleste feilene som fører til tapte midler kommer ikke av at Etherscan viser feil informasjon, men av at brukeren tolker riktig informasjon på feil måte, eller rett og slett ikke sjekker. Disse syv fallgruvene dekker nesten alle sakene vi har gått gjennom i denne artikkelen, og de fleste av dem kan rettes på under et minutt når du vet hva du skal se etter.

Å stole på “Verified”-merket alene, uten å faktisk lese koden eller sjekke proxy-status
Å tolke “Renounced ownership” som bevis på trygghet, uten å sjekke roller og proxy-admin
Å kopiere kontraktadresser fra søkeresultater eller kommentarfelt i stedet for den offisielle kilden
Å bruke V1-API-endepunkter i nytt prosjektarbeid, selv om de delvis fortsatt fungerer, siden Etherscan offisielt har faset dem ut til fordel for V2
Å ikke håndtere ratebegrensning i skript, slik at automatiserte sjekker stopper opp eller gir ufullstendige resultater midt i en kjøring
Å anta at holderfordelingen på nettsiden automatisk har filtrert bort likviditetspooler og broer, når den i praksis ofte trenger manuell verifisering
Å overse at et kall gjennom en proxy kan treffe en helt annen implementasjon enn den du sist sjekket, siden admin kan bytte den når som helst

Feilsøking: vanlige feilmeldinger og løsninger

Både nettsiden og API-et gir av og til feilmeldinger som er vanskelige å tolke om du ikke har sett dem før. Tabellen under samler de du mest sannsynlig møter på i løpet av stegene over, sammen med den vanligste årsaken og en konkret løsning.

Feilmelding	Vanlig årsak	Løsning
Max rate limit reached	For mange kall per sekund for planen din	Legg inn forsinkelse eller kø-styring, vurder høyere plan
Invalid API Key	Feil eller manglende nøkkel i .env	Sjekk at ETHERSCAN_API_KEY er lastet riktig med dotenv
Contract source code not verified	Kontrakten er faktisk uverifisert	Behandle den som uverifisert, ikke som en feil å fikse
NOTOK i status-feltet	Generisk API-feil, ofte feil parameter	Dobbeltsjekk module, action og chainid i URL-en
nonce too low	En annen transaksjon fra samme lommebok er allerede i kø	Vent til forrige transaksjon bekreftes før du sender på nytt
Tomt resultat fra getsourcecode	Feil chainid, kontrakten finnes ikke på valgt kjede	Bekreft hvilken kjede kontrakten faktisk er deployet på
HTTP 429	For mange kall på kort tid fra samme nøkkel	Implementer token bucket-forsinkelse slik Etherscan anbefaler
Feil ABI eller “could not decode result data”	Kontrakten er en proxy, du leste feil ABI	Hent implementasjons-ABI via “Read as Proxy” på Etherscan

De fleste feilmeldingene er, ifølge Etherscans egen dokumentasjon, knyttet til enten ratebegrensning eller feil parametere i kallet, ikke til at tjenesten selv er nede. Får du vedvarende problemer selv etter å ha rettet opp parameterne, er det verdt å sjekke Etherscans statusside eller sosiale kanaler for kjente driftsproblemer før du fortsetter å feilsøke egen kode.

Avanserte tips for daglig bruk

Når du har kjørt gjennom de tolv stegene noen ganger, blir rutinen raskere. Disse tipsene er det som skiller en engangssjekk fra en vane du faktisk klarer å holde fast ved over tid.

Bruk chainid-parameteren til å gjenbruke samme skript på tvers av Base, Arbitrum og andre kjeder Etherscan V2 støtter, uten å skrive om logikken
Cache svarene dine lokalt, for eksempel i en enkel JSON-fil eller SQLite-database, for adresser du sjekker ofte, slik at du ikke bruker opp det daglige kallbudsjettet unødvendig
Kombiner Etherscan med en simuleringstjeneste før du signerer en kompleks transaksjon, for å se forventet utfall uten å sende den til kjeden
Sett alltid opp håndtering for HTTP 429 og Etherscans egne feltbaserte feilmeldinger, med en enkel forsinkelsesmekanisme
Lagre blokknummeret eller tidsstempelet sjekken ble gjort på, siden eierskap, fullmakter og holderfordeling endrer seg over tid, og en rapport uten tidsstempel blir fort misvisende
Sett opp et separat, begrenset API-nøkkel-par for produksjonsskript og et annet for manuell testing, slik at en feilkonfigurert test-kjøring ikke spiser opp dagskvoten til overvåkingstjenesten din
Bygg inn en enkel liste over kjente, legitime proxy-admin-adresser (store protokoller du selv stoler på) i skriptet, slik at verktøyet kan skille mellom “ny og ukjent admin” og “kjent, veletablert admin” automatisk

Komplett eksempelprosjekt: contract-check CLI

Satt sammen gir stegene over deg et lite, men komplett prosjekt: contract-check.js fra steg 9 gjør grunnsjekken, watchApprovals fra steg 11 legger til overvåking, og .env-filen holder nøklene dine utenfor kildekoden. Du trenger ikke noen database, betalt skytjeneste eller tredjeparts overvåkingsplattform for å få nytte av dette. Hele prosjektet kjører lokalt på din egen maskin, eller på en billig liten server, og kostnaden er begrenset til hva du eventuelt betaler for et høyere Etherscan-nivå om du skalerer opp antall overvåkede adresser. Mappestrukturen ser slik ut når du er ferdig:

contract-check/
├── .env
├── package.json
├── contract-check.js
└── monitor.js

For å kjøre overvåkingen automatisk hvert tiende minutt, registrer en cron-jobb:

# Kjør overvåkingen hvert 10. minutt
*/10 * * * * cd /sti/til/contract-check && node monitor.js >> monitor.log 2>&1

Resultatet er et verktøy du kan peke mot enhver ny kontrakt før du samhandler med den, og som varsler deg i Telegram dersom en overvåket lommebok plutselig godkjenner en ny, mistenkelig fullmakt. Skriv gjerne ned de faktiske transaksjonshashene fra testkjøringen, slik at du kan slå dem opp på Etherscan i etterkant og bekrefte at beløp, mottaker og status stemmer med det skriptet rapporterte. Den doble kontrollen tar et par minutter, og fanger opp feil i egen kode før de koster deg noe.

Slik utvider du prosjektet videre

Den enkleste utvidelsen er å gjøre CHAIN_ID konfigurerbar fra kommandolinjen, slik at du kan kjøre nøyaktig samme contract-check.js mot en kontrakt på Base eller Arbitrum uten å endre en linje kode, bare ved å legge til en ny parameter. Neste skritt er å legge til holderfordeling og en enkel poengsum, der skriptet summerer opp hvor mange av de syv honeypot-signalene fra steg 5 som er til stede, og gir deg en samlet risikoscore i stedet for rådata du selv må tolke. Vil du gå videre enn det, kan du koble skriptet til en liten database som lagrer historiske sjekker, slik at du kan se om en kontrakt endrer oppførsel, for eksempel ved å bytte proxy-implementasjon, over tid.

Ofte stilte spørsmål

Er Etherscan gratis å bruke?
Nettsiden er gratis for alle. API-et har et gratisnivå på 3 kall i sekundet og opptil 100 000 kall per dag, noe som dekker de fleste personlige prosjekter. Trenger du høyere kapasitet, for eksempel til et overvåkingsskript som kjører kontinuerlig mot flere lommebøker, finnes det betalte nivåer med høyere grenser.

Er et “Verified”-merke det samme som en sikkerhetsrevisjon?
Nei. Det bekrefter kun at innsendt kildekode samsvarer med det som faktisk er deployet på kjeden. Det sier ingenting om koden er trygg, rettferdig eller fri for skjulte privilegier, og en kontrakt kan være fullstendig verifisert og samtidig inneholde funksjoner som lar utvikleren tømme den.

Hva er forskjellen på Etherscan API V1 og V2?
V2 samler alle støttede kjeder bak én base-URL og én nøkkel, styrt av parameteren chainid. V1 krevde separate nøkler per kjede, og ble, ifølge Etherscans eget migreringsnotat, faset ut 15. august 2025. Nytt prosjektarbeid bør derfor alltid bygges mot V2.

Kan jeg bruke samme Etherscan-nøkkel på andre kjeder enn Ethereum?
Ja. En V2-nøkkel er knyttet til kontoen din, ikke til en bestemt kjede, og fungerer på over 50 kjeder ved å endre chainid-parameteren i kallet. Det gjør det unødvendig å opprette separate kontoer for hver kjede du følger.

Hvordan vet jeg om et token er en honeypot før jeg kjøper?
Les kildekoden for mint-, blacklist- og handel-av/på-funksjoner, sjekk om salg har en unormalt høy avgift, og se etter om eierskap faktisk er fjernet på alle nivåer, ikke bare i owner-feltet. Se også på transaksjonslisten for å sjekke om noen andre enn de første kjøperne faktisk har klart å selge.

Kan Etherscan hjelpe meg å få tilbake stjålne midler?
Etherscan kan hjelpe deg å spore hvor midlene gikk, men kan ikke stoppe eller reversere transaksjoner. Sporingen stopper vanligvis ved en miksertjeneste, en bro til en annen kjede, eller et innskudd på en sentralisert børs, og videre oppfølging krever normalt en formell anmeldelse eller hjelp fra et sporingsselskap.

Hvor ofte bør jeg sjekke token-godkjenningene mine?
En rask gjennomgang hver måned er et fornuftig minimum, og alltid rett etter at du har samhandlet med en ny eller mindre kjent protokoll. Mange venter til noe allerede har gått galt, mens vanen egentlig er billigst å bygge før noe skjer.

Er gratisnivået til Etherscan API nok for et personlig overvåkingsskript?
For ett til noen få lommebøker, ja. Overvåker du mange adresser med hyppig polling, bør du legge inn kø-styring i koden eller vurdere et betalt nivå for å unngå å treffe den daglige grensen. En enkel måte å teste dette på er å logge hvor mange kall skriptet ditt faktisk gjør per dag før du bestemmer deg.

Må jeg stole 100 prosent på Etherscan selv for at disse stegene skal virke?
Nei, og det er faktisk poenget. Etherscan viser deg rådataene fra kjeden, men konklusjonen trekker du selv basert på kombinasjonen av signaler. Er du i tvil om noe nettsiden viser, kan du alltid dobbeltsjekke med en uavhengig utforsker som Blockscout for samme kjede.