SAYLOR Explain mint, freeze, metadata, update, transfer-hook, permanent-delegate, close, and other relevant authorities without turning risk flags into unsupported guarantees.
The result you're building
A mint-specific authority report that identifies the token program and extensions, current mint/freeze/metadata/update/delegate/close authorities, ownership/control evidence, observed time, and limitations without calling any token guaranteed safe.
Use this guide when
- Reviewing a Solana token before integration, listing, purchase, or risk report.
- Explaining what authority fields can and cannot do.
Do not use it as a substitute for
- Do not trust token symbol/name/logo to identify a mint.
- Do not interpret a revoked mint authority as proof against liquidity, holder, metadata, delegate, or market risks.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Cluster and exact mint address from an authoritative source.
- Token Program vs Token-2022 program and parsed mint/account data.
- Metadata account/program, extensions, upgradeability/control context where relevant.
- Observed slot/time and independent RPC evidence.
Understand the system before fixing it
Authority value is a capability, not a prediction
A live mint authority can create supply; a freeze authority can freeze eligible accounts. Whether it will happen is unknown.
Token-2022 extensions change the risk surface
Transfer hooks, fees, permanent delegates, default account state, confidential features and close authority require program-specific decoding.
Metadata identity is separate from mint economics
Update authority may change presentation; it does not necessarily control supply, while spoofed metadata can impersonate known brands.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Mint authority present | Supply | Decode authority type/address and owner/control | Additional minting may be possible; quantify current supply and disclose. |
| Freeze authority present | Account control | Decode authority and token program semantics | Eligible token accounts may be frozen under program rules. |
| Authority null | Revoked | Confirm parsed account from correct program/slot | That specific authority is unavailable; other controls still need review. |
| Token-2022 extensions | Program behavior | List/decode every extension | Report transfer fee/hook/delegate/default/close implications individually. |
| Metadata update authority | Presentation | Read metadata account and update authority | Name/symbol/URI content may be mutable; verify mint independently. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Resolve exact mint and program
Why: Lookalike tokens share names and symbols.
Do: Confirm cluster/mint from project and independent explorer/RPC; fetch account owner to identify SPL Token or Token-2022 program.
Read the result: Program owner determines decoder and possible extensions.
Next: Record slot/time and raw account hash/reference.
Step 02 — Decode base mint authorities
Why: Supply and freeze controls are core but frequently misreported.
Do: Read decimals, supply, initialization, mint authority and freeze authority with explicit null/present and address.
Read the result: Null means that exact authority is revoked, not that token is safe.
Next: Compare two sources at nearby slots.
Step 03 — Decode extensions and delegates
Why: Base parser can omit Token-2022 behavior.
Do: Enumerate extensions such as transfer fee/hook, permanent delegate, default state, metadata pointer, close authority and others supported by deployed program; identify control addresses.
Read the result: Unknown/unparsed extension lowers confidence.
Next: Explain concrete capability and trigger.
Step 04 — Decode metadata/control provenance
Why: Presentation and links are attack surfaces.
Do: Resolve metadata account/program, URI, update authority, mutability, collection/creator verification where applicable; fetch off-chain data cautiously with provenance.
Read the result: Metadata can change/disappear and links are untrusted.
Next: Never identify by logo alone.
Step 05 — Analyze controller addresses
Why: Authority owned by multisig/program may differ from single wallet.
Do: Determine account type/owner, multisig threshold/signers when publicly decodable, PDA/program relationship, and upgrade authority implications.
Read the result: Report unknown ownership rather than calling renounced.
Next: Do not deanonymize beyond evidence.
Step 06 — Issue bounded report
Why: Risk consumers need observations separated from inference.
Do: Return authority matrix, capabilities, evidence/slot/time, extensions, missing data, changes since prior snapshot, confidence and explicit non-guarantee.
Read the result: Requery before high-impact action because authorities can change.
Next: Alert authority or metadata changes.
Worked example
Evidence collected
- Mint authority is null.
- Freeze authority remains a live single-key address.
- Metadata update authority is mutable.
- Token-2022 permanent delegate is present.
Decision: The scanner checked one field and made an unsupported global conclusion.
Actions taken
- Decoded correct token program and all extensions.
- Reported each capability and controller separately.
- Added holder/liquidity/market analysis as separate guide inputs.
Why this example matters: A trustworthy decoder never turns one revoked authority into a safety badge.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Mint/cluster/program owner are exact and independently checked.
- Base authorities and every supported extension are decoded.
- Controller account type/ownership is reported or unknown.
- Metadata authority/mutability/provenance are separate.
- Observed slot/time/source and missing data are included.
- No global safety guarantee is inferred.
Rollback or safe recovery
- Revert report to prior snapshot version when parser/RPC data is proven wrong.
- Mark stale/invalid report withdrawn rather than editing history silently.
- Disable automation on unknown extensions until decoder is updated.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| RPCs disagree | Slot/commitment/staleness/parser difference. | Compare context/commitment/raw account and third source. |
| Parser omits extension | Unsupported Token-2022 feature. | Use program-aware decoder/raw data and lower confidence. |
| Authority is PDA | Program-controlled capability. | Identify program and upgrade/control path; do not call ownerless. |
| Metadata URL unsafe | Off-chain untrusted content. | Do not click/sign; fetch isolated and report provenance. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- Mint/cluster/program/slot identity.
- Authority and Token-2022 extension matrix.
- Controller/multisig/program provenance.
- Metadata/update/mutability evidence.
- Capability explanations, missing data, confidence, and disclaimer.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points