Proton (XPR)

The examined promise

This dossier examines what the supplied documentation actually says about Proton, ticker XPR, on network eip155:56, also written BNB Smart Chain. The documentary subject is a single integration record for the contract address 0x5de3939b2f811a61d830e6f52d13b066881412ab inside the pinned Trust Wallet community assets registry. The promise under examination is narrow. We ask whether the documented description, interface labels and network context together establish anything about how this token currently behaves. They do not, and saying so plainly is the point of the exercise.

Two technical terms recur. An integration registry is a community-maintained catalogue of token information and logos that a wallet and other projects may read from. A BEP20 label is a registry tag that a token entry follows a token interface convention on BNB Smart Chain. Neither term implies a live check of the token.

Documentary facts

The pinned Trust Wallet BNB Smart Chain integration record names XPR Network with symbol XPR, documentary address 0x5de3939b2f811a61d830e6f52d13b066881412ab and 4 decimal places. Decimal places describe how amounts are represented in code and do not measure supply or value. The record labels the entry BEP20 and active. Active is a metadata label with no live-network validation behind it in this lot.

The record carries a community-maintained description. It states that Proton is a public blockchain and dApp platform for consumer applications and P2P payments, built around an identity and financial settlements layer that lets users link real identity and fiat accounts, pull funds, buy crypto and use crypto. Every project, economic, partnership, performance, supply, date and adoption statement inside that description is an attributed registry claim, not an independently established issuer statement and not an operational observation. The dossier explains those stated aims only with that attribution. The general ERC-20 interface specification supplied here is a separate document from this token implementation and describes what a conforming fungible token contract should expose: totalSupply and balanceOf reads, transfers, authorized third-party transfers, approvals and remaining allowances. An allowance is the amount a named spender may use, and a repeated approval overwrites that amount. Name, symbol and decimal-place metadata are optional in that standard. The registry README describes a community-maintained registry used by the wallet and other projects, notes that additional token information is optional and unavailable on-chain, allows anyone to submit assets, states that inclusion does not imply a partnership with listed projects, and excludes brand-new tokens from submissions. The smartchain network-context record supplies documentary context for entries in the same pinned directory, and that is all it supplies.

What remains unknown

No independent control observation, beneficial ownership check, usage measurement, client adoption evidence, supply figure, concentration analysis, liquidity observation or complete incident history was supplied. Deployed bytecode, actual controller permissions and current network operation were not verified. The status of every scored criterion is unknown, and the calculated result is unrated with 0% scoring coverage. Identity, supply and control are listed as missing essential criteria. This is a documentation lot, and a documentation review is not an independent operational verification. Missing evidence does not make the project fraudulent or unsafe. It means the questions are open.

Consequences for a reader

A registry entry can be accurate as a catalogue line and still tell you nothing about whether code was deployed, who controls it, whether anyone uses it or what a holder actually owns. The quoted description invites readers to picture a working identity and payments platform. That invitation comes from a registry claim, and the supplied sources contain no independent observation that would confirm or refute it. The interface specification describes required behaviour, not this token's behaviour, so an ERC20 style label establishes no checked compliance and no deployed implementation. The README adds a scope limit worth remembering: the registry excludes brand-new tokens, so it cannot serve as an exhaustive inventory of recent launches. Anyone treating inclusion, an active label or a familiar interface name as reassurance is reading a metadata claim as an operational fact.

Verdict

Unrated, with 0% scoring coverage. The documented identity is internally consistent across the supplied summaries and clearly scoped. Operational strength, control and current behaviour remain unproven. Documentary address matching establishes no current program behavior, deployed control or safety. Criteria such as identity, supply and control need independent evidence before any score could be justified, and none is present in this lot.

Evidence that would change this assessment

Concrete research questions follow from the gaps above. Which bytecode is deployed at the documented address, and does it match any published source? Which addresses can mint, pause, freeze or upgrade the token, and under what keys or governance? What is the current supply, and how is it distributed across holders? Who are the beneficial owners of controlling keys? Is there any dated, independent record of transfers, integrated clients or incidents? What does the token itself grant a holder, if anything? Answers would come from reproduced identity checks, independently dated network observations and criterion-specific evidence, followed by calibration and editorial review. Until that evidence arrives, this dossier keeps the unrated status and the 0% coverage figure exactly as calculated.