A review covers a particular implementation, not every future version.
Programs and stored state
Solana programs contain executable logic, while accounts hold the state that instructions read or modify. Deployment and upgrade arrangements determine whether program code can change. The official program documentation describes upgrade authority. This is a different control from a token’s mint authority, so revoking token issuance does not by itself prove that an application’s program can never be updated.
Change can be useful and consequential
Upgradeability lets maintainers repair defects and add features, but users must understand who can authorise those changes. A multisignature approval process differs from a single key. A time delay differs from immediate execution. These controls should be described separately rather than collapsed into a generic “decentralised” label or inferred from the size of a community.
A review-matching example
Suppose a security report examines version A, while the deployed program now runs version B. The existence of the report does not establish coverage of B. A reader needs the reviewed commit or build, the deployment identity and a change record. The example is deliberately generic: it demonstrates a verification task, not an allegation about a particular project.
What to record
Record the program address, observed upgrade authority, governance mechanism and the version linked to any security review. Note unknowns explicitly. An immutable program can still contain defects or depend on mutable outside systems, so removing upgrade rights is not a complete safety argument. The aim is to explain who can change what and how a user would discover that a change occurred.
Sources & further reading
Sources checked 7 October 2026. Source-linked explanatory content; not personalised investment advice. Found an error? Request a correction.
