
Scroll (SCR)
Documentary contract0xd29687c813d741e2f938f4ac377128810e217b1b
Unrated · 0% Evidence coverage
Operational strength remains unproven; unrated with 0% scoring coverage.
Documentary mechanisms alone cannot establish actual network behavior or investment outcomes.
Inspect the evidenceThe source review explains documented mechanisms. Independent network checks remain pending.
The examined promise
This dossier examines the documented purpose and mechanisms of Scroll, presented under the token symbol SCR on network eip155:534352. The stated subject is pinned to a documentary contract address, 0xd29687c813d741e2f938f4ac377128810e217b1b, recorded in the Trust Wallet integration registry.
The promise, as recorded, is a zkEVM-based zkRollup on Ethereum that is meant to offer native compatibility for existing Ethereum applications and tools, drawing on battle-tested cryptographic libraries and open-source development to maintain integrity and safety. That description is a community-maintained registry claim attributed to the pinned entry, not an independently verified issuer statement or an operational observation.
A rollup is a scaling design that executes transactions off the main chain and posts compressed results back to it; a zkEVM is a rollup whose execution environment is intended to run Ethereum-style contracts while using zero-knowledge proofs. Those definitions describe the advertised design only. This dossier does not confirm that any of it is running as described.
Established documentary facts
Several points are established strictly at the documentary level. The pinned Trust Wallet Scroll integration record names the project Scroll with symbol SCR, the documentary identifier 0xd29687c813d741e2f938f4ac377128810e217b1b and 18 decimal places. Decimal places describe how token amounts are represented; they establish no current supply and no value. The entry is labelled SCROLL and active, where active is a metadata label rather than a live-network validation.
The broader Trust Wallet Assets registry describes itself as a community-maintained catalogue of token information and logos spanning multiple blockchains, used by the wallet and other projects. It states that additional token information is optional and not available on-chain, that anyone can submit assets, and that inclusion does not imply a direct partnership with the listed projects. It also excludes brand-new tokens from submissions, so the registry cannot serve as an exhaustive inventory of recent launches. Its scripts and documentation use the MIT licence. A separate pinned directory context names Scroll and establishes documentary directory context only.
The ERC-20 specification is a standard interface for fungible tokens in smart contracts. It defines reads such as totalSupply and balanceOf, transfers, third-party transfers after authorisation, approval and remaining allowance. An allowance is the amount a named spender may use, and a repeated approval overwrites that amount. The specification states that callers must handle a false transfer result, and it describes Transfer and Approval events. Name, symbol and decimal-place metadata are optional under the standard. This is the generic specification, separate from any particular token implementation.
What remains unknown
No independently reviewed observation was admitted for any of the listed criteria in this documentary lot, so identity, usage, token role, supply, concentration, value capture, control, security, governance, accountability, incidents, continuity and execution all remain unknown. The scoring coverage stands at 0 percent and the asset is unrated. Identity, supply and control are flagged as missing essentials.
Beyond the criteria, present independent control, beneficial ownership, usage, client adoption, supply, concentration, liquidity and the complete incident history remain unverified. No deployed bytecode, current controller, mainnet deployment, functioning implementation, token right or security audit was checked. The directory material is maintained by a wallet project through community submissions, so its project descriptions are documentary claims rather than independently verified issuer statements. A documentation review is not an independent operational verification.
Consequences of the evidence gap
The practical consequence is that documentary mechanisms alone cannot establish actual network behaviour or investment outcomes. A registry label being present and active does not demonstrate that a mainnet is running, that any contract is deployed as described, or that the token carries the rights a reader might assume. The ERC-20 label in the registry establishes no independently checked compliance, no actual deployed implementation, no controller permissions and no security properties, and no token transaction was performed in this review.
For a reader, this means the material here should be read as documentation about a subject, not as confirmation of operations, safety or performance. Missing evidence does not by itself make a project fraudulent or unsafe; it means the questions that would support a verdict are still open, and any conclusion drawn beyond the documents would be unsupported.
Verdict
Operational strength remains unproven. Scroll is unrated, with 0 percent scoring coverage. The documentary subject is identified and its recorded claims are pinned and attributable, but no criterion-specific observation was admitted and no independent operational verification was performed. This verdict is provisional and rests only on the supplied summaries.
Evidence that would change the verdict
The rating could move only after evidence specific to each criterion is gathered. Concrete research questions include: what is the independently reviewed identity of the current contract controller? What are the present supply and holder concentration figures? Does the token carry defined governance, fee or value-capture rights, and under which document? Is there a dated independent operational observation of the network, and does a reproduced identity check confirm the documentary address matches deployed behaviour? Are there completed independent audits, and what do client end-of-support records state?
Answering those would require reproduced identity checks, independent dated network observations and criterion-specific evidence, followed by calibration and editorial review. Until such evidence exists and is reviewed, the unrated status stands.
Each check earns its result.
| Check | Weight | Result |
|---|---|---|
| Exact asset identityEssential | 3% | Verification pending |
| Observable use | 15% | Verification pending |
| Economic role of the token | 10% | Verification pending |
| Supply mechanismsEssential | 10% | Verification pending |
| Ownership concentration | 8% | Verification pending |
| Value capture | 7% | Verification pending |
| Control powersEssential | 10% | Verification pending |
| Security verification | 7% | Verification pending |
| Decision process | 8% | Verification pending |
| Accountability | 7% | Verification pending |
| Incident history | 6% | Verification pending |
| Operational continuity | 4% | Verification pending |
| Execution conditions | 5% | Verification pending |
Family-specific checks: Observable usage, token necessity and dependencies.
Inspect the evidence
Sources behind this analysis
Trust Wallet: captured Scroll record for Scroll
The pinned Trust Wallet Scroll integration record names Scroll with symbol SCR, documentary identifier 0xd29687c813d741e2f938f4ac377128810e217b1b and 18 decimal places. Decimal places describe amount representation and establish no current supply or value. The entry is labelled SCROLL and active. Its community-maintained description states: "Scroll employs a multifaceted approach to ensure its security, leveraging the robustness of battle-tested cryptographic libraries and the principles of open-source development. This approach is designed to maintain the integrity and safety of its zkEVM-based zkRollup on Ethereum, which is crafted to offer native compatibility for existing Ethereum applications and tools.". Every project, partnership, grant, economic, performance, supply, date and adoption statement above is an attributed registry claim, without independent issuer or operational verification. The directory label does not establish a mainnet deployment, functioning implementation or present token rights. No deployed control, beneficial ownership, supply, reserves, use, safety, complete incident record or investment outcome was checked. The generic application family identifies only a documentary token subject; economic niche and scoring criteria remain unclassified and unknown. The general ERC-20 specification is separate from this token implementation.
Inspect the primary source ↗Trust Wallet: pinned Scroll directory context
The pinned community-maintained Trust Wallet scroll directory context names Scroll. This establishes documentary directory context only. No performance, consensus, mainnet RPC response, current deployment, control or security claim is independently verified.
Inspect the primary source ↗Trust Wallet Assets: README.md (bbe582d25a22)
The Trust Wallet Assets README describes a community-maintained registry of token information and logos across blockchains, used by the wallet and other projects. It says additional token information is optional and unavailable on-chain. Anyone can submit assets, and inclusion does not imply a direct partnership with the listed projects. It also explicitly excludes brand-new tokens from submissions, so this source cannot provide an exhaustive inventory of recent launches. The README states that its scripts and documentation use the MIT license. This source is the wallet project's own integration registry, maintained with community submissions. Its project descriptions are documentary claims from that registry, not independently verified issuer statements or operational observations. The active status is a metadata label, with no live-network validation. No deployment bytecode, controller, supply, reserve, use, concentration, liquidity, security audit, incident completeness or investment return has been established.
Inspect the primary source ↗Ethereum ERC-20: pinned token interface specification
The pinned ERC-20 specification describes a standard interface for fungible tokens in smart contracts. It defines totalSupply and balanceOf reads, transfers, third-party transfers after authorization, approval and remaining allowance. An allowance is the amount a named spender may use; a repeated approval overwrites that amount. The specification says callers must handle a false transfer result and describes Transfer and Approval events. Name, symbol and decimal-place metadata are optional in the standard. These interface requirements describe what a conforming implementation should do. A wallet ERC20 label establishes no independently checked compliance, actual deployed implementation, controller permissions, token use, supply or security. No token transaction was performed in this review. Copyright and related rights are waived under CC0.
Inspect the primary source ↗Only original summaries are distributed. Licensed raw market data stays private.