Smart Contract Analysis Statement

Contract Analysis

The Plexrum (PLXR) contract implements an ERC-20 token with a fixed supply of one billion units, holder-burnable balances, renounceable ownership, and no post-deployment minting. It is deployed on Ethereum rather than the chain targeted by the previous revision. The design remains deliberately minimal and follows the well-trodden OpenZeppelin pattern for non-inflationary tokens. There are no fee-on-transfer mechanics, no blacklist, no pause, and no rebase. The token passes every ERC-20 conformance check, including return types, view modifiers, and indexed event parameters, and symbolic execution surfaced nothing beyond a known false positive in compiler-generated constructor scaffolding. Both findings raised against the previous revision of this contract have been addressed, and two new items were introduced by that remediation:

• Ownership transfer is now two-step, which resolves the previously-reported risk that a mistyped recipient would hand the token over irrecoverably. This was verified by test: the transfer does not take effect on proposal, an unauthorised acceptance reverts, and a mistyped pending owner can be overridden by proposing again before acceptance. Renunciation remains available by design, matching the project's stated intent to renounce once the token is in distribution.
• The constructor was marked payable to capture a small deployment-gas saving, as previously recommended. The token has no receive function, no fallback, and no withdrawal path of any kind, so any ether attached to the deployment transaction is frozen permanently. The saving is roughly two hundred gas, once, which is not a trade worth making against an unrecoverable loss. Removing the modifier is the recommended resolution.
• The Solidity pragma is now pinned rather than floating, which was the substance of the previous recommendation, but it was pinned to a different exact version from the rest of the project. Two exact pins with no overlapping range is a stricter failure than the floating caret it replaced, because the caret was at least satisfiable by the newer compiler. The practical consequences are that the project cannot be built under a single declared compiler version, and that no deployment script, integration test, or periphery contract can reference the token alongside the presale or the vault. Aligning every file to the same exact version resolves this.
• The total supply constant now uses scientific notation, consistent with the rest of the codebase. Cosmetic, and confirmed applied.

Ownership Privileges

The ownership of the contract has been retained by the deployer and is renounceable per the project's design. The owner retains the full but deliberately narrow set of privileges:

• Propose a transfer of ownership to another address. The transfer only takes effect once the proposed owner accepts it, and the proposal can be replaced or redirected until then.
• Renounce ownership permanently, which the project indicates is the intended end state once the token is in distribution.
• No ability to mint new tokens. Total supply is locked at one billion forever, and the only mint call is in the constructor.
• No ability to pause transfers, freeze accounts, blacklist holders, or take fees on transfers.
• The contract has no upgrade path, no proxy, and no admin module beyond ownership.
• Burn is a holder-side function only. No administrative burn exists, so the owner cannot reduce another holder's balance.
• The contract exposes no rescue function and holds no value by design. Note that ether attached to the deployment transaction would be held and would not be recoverable, which is the open finding above.
• There are no fee sinks, treasury hooks, or routing of transfer value to external addresses.

Security Features

The contract implements several positive security features:

• Fixed and immutable supply minted entirely at construction time, removing any possibility of post-deployment inflation.
• Two-step ownership transfer, so a proposed owner must accept before any privilege moves. This is an improvement over the previous revision and closes the only material finding raised against it.
• Direct inheritance from the OpenZeppelin v5 ERC-20 reference implementation, which delegates transfer, approval, and event-emission semantics to a widely-reviewed base.
• Holder burn provides a clean, supply-reducing exit path with no administrative interaction.
• Full ERC-20 conformance confirmed by automated checking. The only flagged item is the long-deprecated approval race condition, which the library treats as an integrator concern and for which it exposes safe-increase, safe-decrease, and force-approve helpers. This is expected behaviour rather than a contract defect, though the project should document the recommended helpers for integrators.
• Static analysis with deterministic scanners, symbolic execution, and pattern matching found no exploitable issue in the token. The only items raised are the ownership and pragma observations noted above.

Note - This audit report consists of a security re-analysis of the PLXR smart contract following remediation of the previous engagement's findings. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Plexrum team. Other contracts associated with the project were audited in parallel but reported separately, and the broader Plexrum ecosystem was not part of this engagement. Note that the submitted repository did not compile as delivered and had to be reconstructed for analysis, so re-verification against a building repository is required before deployment. We recommend investors do their own research before investing.