The public constant INITIAL_SUPPLY returns 1,000,000,000, while every other amount the contract reports, including the total supply, balances, allowances and event values, is expressed in base units with eighteen decimals. The constructor bridges the two by multiplying by ten to the power of eighteen, but anyone who reads the constant directly receives a figure that is a billion billion times smaller than the total supply, which leads to wrong results in any percentage, vesting or reward calculation that mixes the two. The word initial also suggests that the supply might change, although it cannot.

The whitepaper, version 0.3 of October 2026, describes a proposed token used for fee discounts, staking with penalties and governance over fees, networks, treasury and upgrades, and says that supply, allocation, vesting and emissions still require product and legal approval. The deployed contract is a plain token with a supply fixed permanently at one billion, issued three times over to a single account. It has no voting power or delegation, so standard on-chain governance cannot use it without a wrapper token, it has no staking or fee logic, and it does not support the signed transfer authorizations the whitepaper relies on for payments. Keeping such utility outside an immutable token is a sound design choice, but the published specification and the deployed contract currently describe different things, and no document links the project to this contract address.

The token implements neither the permit extension for signed approvals nor the transfer with authorization standard, and there is no signing domain, no nonce tracking and no signature verification anywhere in the code. Every allowance therefore needs its own on-chain transaction paid by the holder, and the token cannot take part in the gasless signed payment flow that the whitepaper describes for its payment protocol, so paying fees in this token will require a standard approval followed by a transfer, or a separate approval router. The compensating benefit is that the contract has no signature surface at all, which rules out signature replay, cross-chain replay, deadline handling errors and signing domain drift.

Flattening the source pulled in error definitions for two other token standards, fifteen errors in total, that nothing in this contract can raise, together with three library helpers that are never called, one of which is an internal burn routine. None of this produces deployed code, so there is no gas or size cost, which the exact bytecode match confirms. The only cost is a longer source to review, and the presence of an unused burn routine can lead readers to believe that the token is burnable when it is not.

The file contains seven version statements with four different ranges inherited from the library and from the project file, and the project contract itself accepts any compiler from 0.8.20 onwards, including releases with known defects. The deployed bytecode was produced with exactly version 0.8.34 and has been matched byte for byte, so the floating range has no effect on the live contract. It would only matter if someone recompiled the source with a different compiler, for example for a redeployment or a fork.

Compiler version 0.8.34 is listed in the official compiler bug registry with six known defects, and block explorers may display a warning on the contract page. Each was assessed against this contract. Four of them only occur with the alternative compilation pipeline or with the optimizer enabled, and this contract was compiled with the standard pipeline and the optimizer switched off. One requires a custom storage layout specifier, which the contract does not use, and one requires deleting a single element of an in-memory byte array, which the contract never does. None of the six can therefore affect the deployed code.

When transferFrom uses up part of an allowance, the library updates the stored allowance without emitting an approval event. This is deliberate upstream behaviour that saves gas and is permitted by the standard, and testing confirmed that a delegated transfer produces exactly one log entry. Services that rebuild allowances purely from event history, without reading the contract state, will therefore report allowances that are higher than the real values.

The increaseAllowance and decreaseAllowance helpers, which earlier versions of the library provided, were removed in the version used here and are absent from the token. Older integrations that still call them will fail. Together with the approval race, this means the only way to change an allowance is to overwrite it completely.

The short project contract has no documentation comments at all, so nothing explains the purpose of the owner role, the unit of the initial supply constant or the intended distribution of the minted supply. The original source file is named xpaucontract, which appears to be a misspelling, and the explorer listing is a single flattened file in which the project code appears only at the very end, after more than seven hundred lines of library code.

The constructor mints the full issuance of one billion tokens to the address supplied at deployment and makes that same address the owner. On the live deployment this is 0x406D2788E9709FDF90289c216B2E82A7847aB461, an ordinary single key account with no contract code. It has never sent a transaction, it holds a small amount of ETH for gas, and it still holds one hundred percent of the supply. The same account also holds the entire supply of two further deployments of this token. There is no vesting contract, no time lock, no wallet requiring several approvals and no published split between liquidity, treasury, team or ecosystem allocations, and the project whitepaper states that supply, allocation and vesting are still subject to approval. The token gives its owner no power over other holders, so this is a custody matter rather than a coding defect, but it is the dominant risk for anyone who acquires the token, because one private key can move or sell the whole float in a single transaction, and a lost or stolen key would strand or surrender it.