- What's a smart contract on QRL 2.0?
- Bytecode deployed to the chain that gets its own address and can be called by transactions. QRL 2.0 uses QRVM — a fork of EVM — and Hyperion (a Solidity fork) as the source language. Standard EVM patterns compile cleanly; most Ethereum-targeted Solidity contracts work after re-compilation with `hypc`.
- Why do tokens and NFT collections appear here too — isn't that what /top-tokens and /top-nft are for?
- A token IS a smart contract — there's no separate concept on the chain. This page is the full QRVM catalogue: every deployed contract, regardless of whether it implements QRC-20, QRC-721, QRC-1155, or something custom like a DEX or DAO. The columns here are developer/auditor-focused: deployer, verification status, deploy block, lifetime call count. the Top Tokens and Top NFTs leaderboards are opinionated views over the SAME contracts, focused on token-user signals: symbol, holders, supply, items. Use this page to discover or audit contracts; use the leaderboards to browse what's hot among token-users.
- What do the three verification states mean?
- ✓ Verified (full): source compiled byte-for-byte to the deployed bytecode, including the CBOR metadata hash — strongest guarantee. ⚠ Verified (partial): bytecode matches but metadata-hash diverges (usually different optimizer settings or file paths) — the logic is identical, only the build environment differs. ✗ Unverified: no source uploaded; only the raw deployment bytecode is on chain.
- Does 'verified' mean the contract is safe?
- No. Verification proves that the published source compiles to the deployed bytecode — it does NOT certify the contract is bug-free, well-designed, or trustworthy. Always read the source code (now possible thanks to verification) before interacting with significant value.
- Verified is not Audited — what's the difference, and why is there no Audit column?
- Verification = the published source compiles to the deployed bytecode (a reproducible build, mechanical check). Audit = a security firm has reviewed the source for bugs, design flaws, and economic risks. Etherscan shows audit badges because it has curated business partnerships with firms like CertiK, Hacken, OpenZeppelin Defender, and ConsenSys Diligence — that's a business product, not chain-derivable data. Quantascan doesn't have those partnerships, so rather than showing an always-empty Audit column we omit it. Verification is the chain-derivable half: when it's marked Verified, anyone can read what the contract does and run their own review or hire their own auditor.
- How do I verify my own contract?
- Use the verify-form on the contract detail page (`/contract/{address}`). You upload the Hyperion source files, pick the compiler version (`hypc`), set the optimizer config, and the backend recompiles and bytecode-matches. Match-grade (full / partial) shows up on this list once the job completes.
- What does the Similar column mean?
- It counts how many other contracts on QRL 2.0 share the exact same init-bytecode (constructor code + constructor arguments), via a SHA-256 over the deployment input. A count of 1 means the contract is unique. Higher counts almost always signal a factory pattern (one deployer contract mints many copies, e.g. a token factory) or a popular template that's been deployed by different parties. Click the number to see the full list of clones on the contract detail page.
- Which license should I look for in the License column?
- It's the SPDX identifier from the source-file header (`// SPDX-License-Identifier: MIT`). Common values: MIT / Apache-2.0 / BSD-3-Clause = permissive (you can fork freely); GPL-3.0 / AGPL-3.0 = copyleft (forks must also be open under the same license); BUSL-1.1 / SSPL = source-available-not-OSS (you can READ but not necessarily COMMERCIALISE); UNLICENSED / blank = no permission granted — even though the source is published, the deployer hasn't waived copyright. Treat unknown licenses as 'all rights reserved' when in doubt.
- What does the Events 24h column show?
- Count of logs emitted by the contract in the last 24 hours — derived from `qrl2_logs` filtered to that contract's address. A high number means it's actively in use (heavy DEX, popular game contract, etc); zero means it's dormant or only callable. Sort by 'Active' to surface the busiest contracts.
- Are QRL 2.0 contracts quantum-resistant?
- Indirectly. There are no special quantum-safe opcodes inside the QRVM bytecode — contracts execute the same as on Ethereum. Quantum resistance lives at the chain layer: every transaction that called or deployed the contract was signed with ML-DSA-87, a post-quantum signature scheme. The chain itself is quantum-resistant; contract logic is portable from Ethereum-style EVM.
- Does the original QRL chain have smart contracts?
- No. The original QRL chain — the Proof-of-Work predecessor — has no virtual machine; it only supports fixed transaction subtypes (transfer, token, message, slave), each signed with XMSS. Smart contracts are a new capability introduced on QRL 2.0, the EVM-compatible Proof-of-Stake chain that succeeds it. That's why this page exists only on QRL 2.0.