Freeze ownership and authority

EN source master · P08-L04 · 45 minutes estimated · needs_review

An “ownership renounced” badge can coexist with an active pause role or an upgrade controller. A removed mint authority can coexist with a freeze authority. These statements may each be true while the broad conclusion “nobody has control” is false.

This lesson teaches a layered control map. You will connect each privilege to its object, current holder, condition and possible administration path. The result is an evidence record, not a safety score or an accusation.

Define the controlled object

Do not use owner without a noun. A Solana data account's program owner, a token-account authority, an EVM Ownable owner and an NFT position owner are distinct fields. Their names resemble one another but govern different mechanisms. Write the field and object alongside the value.

Separate token balance control, mint-level restrictions, application roles and code-changing authority. A finding about one layer cannot erase a permission at another. For example, a token mint may lack a mint authority while an application interacting with the token remains upgradeable. Review the application's role separately rather than assuming it governs the standard Token Program itself.

A control map is a graph of capabilities, not a graph of human identities. A listed authority can be a user account or a program-mediated address. Public account labels do not establish who has the keys or whether multiple accounts share a controller.

Understand freeze as state restriction

Solana's freeze mechanism preserves token-account owner, mint and balance while preventing the documented receiving, transfer and burn operations until thawed [S08-FREEZE]. It is not a balance deletion or a transfer to the freezing authority.

State and authority must be recorded separately. A freeze authority can exist while an account is currently unfrozen. Conversely, a frozen-state observation does not tell you that a particular human caused it. Ask for the successful operation and its authorization if attribution matters.

Revocation removes a selected authority role, not a universal collection of powers [S08-SET]. Do not assume a mint-role revocation changed freeze state. Existing frozen accounts and possible recovery/thaw paths need their own examination; avoid describing a narrow revocation as proof every account is transferable.

Inspect application roles beyond Ownable

OpenZeppelin Ownable renunciation disables functions protected by its owner check, while role-based permissions are a separate pattern [S08-ACCESS]. Whether a deployed token combines these patterns is a code and state question. If a pauser role remains, owner renunciation alone cannot remove it.

Build a table for ownership, pause, grant/revoke roles and upgrades. For each row record the actual check, present authority, administration path and uncertainty. A role name is descriptive only until tied to a reachable operation. “PAUSER” in metadata is not a proof of a pause function.

A control may depend on a timelock or multisig. Verify the relevant contract, threshold, delay and bypass conditions rather than accepting a badge. A delay is a time condition, not disappearance of control. A multisig threshold describes signatures, not necessarily independent humans.

Trace proxy and implementation control

For ERC-1967-style proxies, distinguish the implementation or beacon linkage from the optional admin slot. A beacon resolves logic for associated proxies; UUPS-style authorization may reside in implementation logic, so an empty admin slot alone is not a complete conclusion [S08-PROXY; S08-UUPS].

A proxy's user-facing address may stay the same when its rules change. Pin the implementation to the reviewed context, then inspect the path that can change it. Do not audit a verified implementation page and leave the proxy link unchecked. A later implementation can invalidate prior behavior assumptions.

This lesson does not teach upgrade execution. It teaches how to describe the supplied authorization path read-only. If the controller's internal rules are unavailable, mark them unknown even when the external authority address is known.

Distinguish Solana program upgrades from mint roles

Under Solana loader-v3, program upgrades depend on program upgrade authority; removing that authority makes that program immutable [S08-DEPLOY]. This is not the mint's mint-authority field. It applies to the reviewed program and loader mechanism, not every connected contract or off-chain service.

A mint governed by a standard Token Program should not be casually described as independently upgradeable just because a custom application uses it. Name the custom program and explain its relevance. In the fixture, PROGRAM-X is an auxiliary application, not the Token Program owning MINT-F.

Immutability is bounded to the code object. It does not prove honest users, immutable metadata, sufficient liquidity or secure surrounding systems. Likewise, active upgrade authority proves a capability under conditions, not that the code will change maliciously.

Report a layered result

A defensible sentence names the context and limits: “At S0 the owner field is renounced, while PAUSER remains assigned and the proxy upgrade controller is supplied but its internal threshold is unknown.” This is more informative than a categorical “decentralized” label.

Ask whether a claim can be falsified by one remaining row. “No privileged controls” is contradicted by one proven live capability. A narrow claim such as “the Ownable owner role is absent” can remain supported even when the broad statement fails. Preserve both.

• Freeze state: operation restriction on a token account.
• Ownable owner: authority under a particular owner-check pattern.
• Role holder: account satisfying a specific membership check.
• Upgrade controller: authority governing a code-change path.
• Beacon: proxy logic-linking mechanism.
• Timelock: condition imposing delay on specified operations.

ILLUSTRATIVE — FIX-P08-04. Separate fictional objects at S0.

PROGRAM-X is not the Token Program governing MINT-F. The fixture does not supply the code effects connecting this auxiliary app to the mint.

OBSERVED in fixture: F remains, V is frozen, P/G remain and C/U are supplied upgrade authorities.

INFERRED: “All controls removed” is contradicted by these separate capabilities. Renounced owner is a narrower supported statement about P2.

UNKNOWN: C's internal rules, human controllers, who froze V and PROGRAM-X's exact application effects.

INSUFFICIENT EVIDENCE: Freeze does not mean V's balance was destroyed. An absent owner does not prove no roles or upgrades. U does not prove the standard Token Program is controlled by U.

Using owner without its object; confusing frozen balance with zero; assuming an empty proxy admin slot excludes all upgrades; interpreting a multisig label as verified independent control; and merging auxiliary-program authority with mint authority.

Produce four control layers: account state, mint roles, EVM application roles and implementation-change paths. Rewrite “all ownership is renounced so everything is immutable.” List the next evidence required for C and V.

• Name every owner field's object.
• Separate authority from current state.
• Inspect roles after ownership renunciation.
• Resolve logic and upgrade paths at the same context.
• Verify thresholds/delays rather than labels.
• Bound immutability to the reviewed object.

Control is layered. A removed role establishes a narrow fact; active roles and code-change paths need separate review.

Freeze is a restriction, not deletion. Owner renunciation is not all-control renunciation. Proxy, program and mint authorities are distinct.

Four-lane permissions map with F1–F3,P1–P3,X1 pointers; show unchanged frozen balance 50. Draw PROXY-Q→LOGIC-Q and separate C controller; PROGRAM-X/U isolated from MINT-F. Mark C configuration unknown.

Illustrative layered controls; owner absence is a narrow claim.

Use deterministic SVG/HTML or charts with text alternatives, dark navy/black and restrained cyan, electric blue and violet. Label every quantity and uncertainty. At 390px stack panels; 768px/desktop and Arabic RTL verification remain future asset work. Keep identifiers LTR and factual axes/edge directions unchanged. Use only the official supplied ZECOIN mark if branding is added. Both records are specifications, not delivered assets.

Use RADAR for the lesson's bounded educational purpose only if network support, exact identity, fields and provenance are verified. No runtime endpoint or provider capability is asserted by this content. Use the embedded offline fixture without paid access. Missing data stays unknown; no wallet connection, transaction signature, token launch or live trade is required. Academy progress, payments and referrals never change Radar evidence. A Diagnostic Passport preserves observations and limits, not a price prediction or safety certificate.

• OpenZeppelin 5.x Proxy — Transparent, beacon and implementation-based UUPS upgrade mechanisms; actual authorization needs inspection. Checked 2026-09-30.
• Solana Freeze Account — Account-state restrictions distinct from amount or ownership. Checked 2026-09-30.
• Solana Set Authority — Role-specific changes and revocation; not a global safety verdict. Checked 2026-09-30.
• OpenZeppelin 5.x Access Control — Ownable and role-based privilege patterns; inspect actual deployed authorization. Checked 2026-09-30.
• ERC-1967 Proxy Storage Slots — Implementation, beacon and optional admin slots; mechanism-specific inspection. Checked 2026-09-30.
• Solana Program Deployment — Loader-v3 program upgrade authority; not a token mint role. Checked 2026-09-30.

Documentation supports mechanisms, not fictional dataset values. All examples and exercise records are original ILLUSTRATIVE material, frozen in this file. S0/S1 are synthetic context labels; observedAt is null because no live or historical ledger measurement was collected. Re-review documentation and actual deployed behavior before any publication or integration.

P08-L05 after the worked exercise and quiz review.