Bug Bounty
No monetary reward is offered
This programme is recognition-only. The operator of this deployment has not funded a paid bounty, and we would rather say so than let you spend a weekend on a report expecting a payout. Valid reports get a considered reply, a fix, and credit if you want it.
How to report
Email [email protected]. Please include:
- the affected URL or API endpoint, and the exact request;
- what you expected and what happened;
- a minimal proof of concept — the smallest request that shows it;
- for a data-correctness bug: the transaction hash, block height or address, and the number you believe is wrong;
- your name or handle, if you want credit.
Give the operator a reasonable window to fix an issue before publishing it — 90 days is the norm and is what we ask for. Report anything you find in good faith and stop as soon as you have a proof of concept; do not pivot deeper, do not access or exfiltrate anyone else’s data, and do not degrade the service for other readers. Testing that stays inside those lines will not be met with legal action from the operator.
In scope
- Remote code execution, SQL injection, SSRF
- Anything that lets a request reach the index database, the Arc node's non-public interfaces, or the host, is the highest severity we can receive.
- Stored or reflected XSS
- Strings on this site are chosen by contract deployers — token names, symbols, revert reasons, compiler versions. They are sanitised on the way out, and a bypass of that sanitiser is in scope.
- Data correctness that misleads a reader
- A balance, amount, fee or transfer rendered wrong. Confusion between the 18-decimal native USDC scale and the 6-decimal ERC-20 face. An address, contract or transaction attributed to the wrong entity. These can cost someone money and are treated as security issues, not cosmetic ones.
- Rate-limit bypass and denial of service
- A single request that consumes a disproportionate amount of backend work, or a way to evade the per-IP budget, degrades a free service for everyone. Please report it rather than demonstrating it at volume.
- Cache poisoning
- Arc cannot reorganise, so responses keyed to a committed height are cached permanently. Any way to get a wrong answer into that cache is serious and long-lived by construction.
Out of scope
Arcscan has no accounts, no sessions, no cookies, no payments and no user-submitted content. A large part of a standard web-application checklist therefore has nothing to attack, and reports from those categories are closed without a fix:
- Missing security headers, cookie flags, or TLS configuration preferences, with no demonstrated impact. There are no cookies and no sessions on this site.
- Missing SPF, DKIM, DMARC or other email configuration.
- Clickjacking on pages with no state-changing action — which is every page here.
- CSRF on unauthenticated, read-only endpoints. There is no login, so there is nothing to forge.
- Rate limiting reported as an availability issue: the limit is intentional and documented.
- Automated scanner output submitted without a working proof of concept or a described impact.
- Denial of service demonstrated by flooding. Describe the amplification; do not run it.
- Social engineering of the operator, or physical attacks on infrastructure.
- Vulnerabilities in the Arc network, its node software, or any third-party contract indexed by this site. Those belong to their own maintainers, not to Arcscan.
- Content of a smart contract, token or address that this site merely displays — including scams. Report those to the relevant venue; Arcscan indexes the chain, it does not curate it.
- Self-XSS, or anything requiring a victim to paste code into their own console.
What is actually behind this site
Useful context before you start looking. Arcscan is a Next.js frontend, a read-only FastAPI service, a PostgreSQL index and an Arc node. The node is not exposed to the internet by this application, the API has no write endpoints beyond raw transaction broadcast — which forwards to the chain and stores nothing — and the index is written only by the indexer process, never by a web request.
The API contract is published at /apis, generated from the live schema. Live service health is on network status. Both are more productive starting points than a scanner.