Expert · LESSON 04 OF 06

4. Public data, privacy, and token design

By the end, you can assess what solana programs and token extensions reveal, authorize, and make durable.

In this lesson8 field notes · practice · sources · checkpoint

The diagram separates public wallet history, asset and collection state, freeze versus update authority, disclosure, and lost-wallet recovery.Open full-size visual ↗

Read a text version of this diagram

The wallet address and its public transaction history are visible on chain. The credential’s permanent freeze plugin prevents transfer, but it is distinct from the asset or collection metadata update authority. Metadata should contain only public credential facts and an opaque identifier, never a learner’s email, legal name, exam answers, or private course history. Lost-wallet replacement needs a published policy.

PUBLIC WALLET + HISTORY
FREEZE PLUGIN ≠ UPDATE AUTHORITY
ASSET + COLLECTION STATE
DISCLOSURE + RECOVERY

Token-2022 transfer hook account flow. The client resolves the mint-bound ExtraAccountMetaList and includes required accounts; Token-2022 invokes the hook by CPI. Original transfer accounts are read-only in the hook, the sender signer privilege does not propagate, and hook failure rejects the transfer.Open full-size visual ↗

Read a text version: Token-2022 transfer hook account flow

Five lanes show the source wallet signing a transfer, the client resolving the ExtraAccountMetaList PDA derived under the hook program from the literal extra-account-metas seed and mint, Token-2022 invoking the hook Execute instruction through CPI, the hook validating its supplied accounts, and the transaction committing only when every instruction succeeds and otherwise rolling back its instruction state atomically; a failed submitted transaction may still charge its network fee. The original transfer accounts are read-only in the hook. The source owner’s signer privilege does not propagate through that CPI. Additional hook accounts are provided according to the declared metadata; a missing account or rejected policy must not produce a partial token-balance change.

SIGNED TRANSFER INTENT
RESOLVE MINT-BOUND EXTRA METAS
TOKEN-2022 CPI: EXECUTE
HOOK VALIDATES SUPPLIED ACCOUNTS
ATOMIC TRANSACTION: SUCCESS COMMITS · ERROR ROLLS BACK

Compare wallet-bound credential models. Core freezes one credential asset and blocks owner transfer and burn under this issuer policy; Token-2022 NonTransferable blocks transfer but allows owner burns and further issuance by the mint authority.Open full-size visual ↗

Read a text version: Compare wallet-bound credential models

The left panel shows the academy’s Metaplex Core badge: one asset per credential, permanently frozen with no thaw authority, while the issuer rejects a permanent burn delegate that could override the freeze. The collection update authority can still change metadata. The right panel shows Token-2022 NonTransferable: transfer instructions fail, but the token-account owner or delegate may burn and the mint authority may issue more. Neither design hides public wallet activity; inspect metadata and authority state separately.

CHOOSE BY THE GUARANTEE
METAPLEX CORE · ONE ASSET PER CREDENTIAL
TOKEN-2022 · NONTRANSFERABLE MINT
VERIFY PRIVACY AND AUTHORITIES SEPARATELY

FIELD NOTE 01

Assume public chain data can be copied

Solana account addresses, balances, transaction signatures, instruction data, and program logs can be read by anyone with suitable RPC or indexing access. A wallet address is pseudonymous, not automatically anonymous. Funding patterns, repeated counterparties, timing, and account reuse can connect activity to other public or real-world information. Removing a row from an academy database cannot erase confirmed public-chain history or copies already held by explorers and indexers; describe deletion limits honestly. Explain these observations before inviting users to connect a wallet. Never promise that a public-chain application makes a user anonymous unless a specific privacy design and threat model support that claim.

FIELD NOTE 02

Understand mints and token accounts

A token symbol and display name are not unique identifiers; the mint address and token program identify the asset configuration. Token accounts hold balances for a particular mint and owner. A reviewer should inspect mint authority, freeze authority, decimals, and relevant token-account state before interpreting a balance or transfer. Applications should not infer rights from a logo or ticker. The same user may hold different assets in distinct token accounts, and metadata can be incomplete or misleading.

FIELD NOTE 03

Treat Token-2022 extensions as product permissions

Token-2022 adds optional mint or account extensions for behaviors such as transfer fees, transfer hooks, metadata, confidential transfers, non-transferability, and permanent delegates. Extensions are configured as part of mint or account initialization, and some combinations are incompatible. A permanent delegate, for example, can authorize transfers and burns across accounts for that mint, and holders cannot revoke it from their individual accounts. A `TransferFeeConfig` extension reduces the transferred amount by its configured fee and records the withheld units on the destination token account; inspect the active rate, maximum fee, and authority, then explain the expected amount the recipient receives. Future fee settings can be scheduled by the config authority. Use a Token-2022-aware decoder for mint and account state; if the service cannot parse an enabled extension safely, report the configuration as unsupported instead of silently treating it as a classic token. A familiar token interface does not remove these program-specific rules. For a transfer hook, the mint names the hook program and Token-2022 invokes its Execute instruction through CPI on each transfer. The hook can enforce policy or reject the transfer, so a client that omits required accounts may fail even when the holder signed the ordinary transfer fields. The hook’s ExtraAccountMetaList is a PDA under the hook program, derived from the literal seed `extra-account-metas` and the mint address; clients resolve its declared accounts and include them in the transfer instruction. Existing source, mint, destination, and owner accounts from the transfer are read-only inside the hook, and the sender’s signer privilege is not forwarded. Extra accounts receive only the access declared for the hook invocation. Validate the expected mint and account relationships in the hook, test the actual client/aggregator construction path, and confirm that rejected transfers leave token balances unchanged. Treat extension choices as part of product and integration design: most cannot be added after initialization, and some combinations are incompatible; the official reference documents NonTransferable and TransferFeeConfig as one incompatible pair. Solana transactions are atomic across their instructions, so a rejected hook does not leave a partial token-balance update; the network fee may still be charged for a failed submitted transaction.

FIELD NOTE 04

Choose the credential model by its exact guarantees

A Metaplex Core asset gives each learner one individually addressable NFT. In this academy’s issuer policy, its asset-level `PermanentFreezeDelegate` is created frozen with authority `None`; the owner cannot transfer or burn it while frozen, and the issuer rejects `PermanentBurnDelegate`, which could override the freeze. The freeze does not make metadata immutable: the collection update authority remains a separate permission and can change the asset name or URI. Token-2022’s `NonTransferable` extension is a mint-level rule that makes every token account for that mint non-transferable, but the account owner or an authorized delegate may still burn tokens and the mint authority may still issue more. Neither model hides wallet ownership or history. Pick the representation from the required uniqueness, issuance, burn, update, and privacy properties, then verify those authorities from current on-chain state.

FIELD NOTE 05

Separate privacy from authority and transferability

Freezing an account, making a token non-transferable, or assigning a delegate changes what an authority can do; none of those choices automatically hides the account or its history. On a Metaplex Core asset, a PermanentFreezeDelegate governs freezing and transfer lifecycle behavior; it does not by itself remove the asset update authority. A Core asset whose update authority points to a collection can still have its name or metadata URI changed by an authorized collection authority. Inspect the plugin state, asset updateAuthority, collection update authority, and any relevant delegates as separate permissions. A frozen credential may still reveal its owner and activity, and its display metadata may remain changeable. Model privacy, transferability, and metadata control separately so a “soulbound” label does not imply protections the implementation lacks.

FIELD NOTE 06

Design metadata for minimal disclosure and durability

Metadata often lives outside the on-chain account and can be fetched, cached, and copied by gateways or indexers. A content identifier can help identify exact content but does not guarantee that providers will keep it available. Before issuing credentials, verify retrieval through independent providers and keep a controlled recovery copy of the exact approved metadata and image bytes. In a Core asset, the on-chain URI points to the metadata document; while an effective update authority remains, an authorized update may replace that URI. Setting an asset's update authority to None is irreversible and prevents later name, URI, and collection-membership updates; an asset governed through a collection requires checking the collection's authority and immutability choices too. A permanent freeze plugin is not a substitute for this metadata-authority review. In this academy's current passport example, the asset belongs to a collection whose update authority is the issuer, so the issuer can still change the asset's metadata URI even though the badge is frozen. The published credential metadata identifies the learner wallet, level, curriculum revision, opaque credential identifier, and issuer signature; it excludes the learner's name, email, exam answers, and score. Treat even an opaque identifier as linkable if the learner's account or public wallet can be connected to it. Publish only fields needed for the asset's purpose. Check image, JSON, authority state, independent retrieval, and recovery copies before irreversible settings make later repair impossible.

FIELD NOTE 07

Recognize wallet linkage and off-chain joins

A web account, email, analytics event, and wallet address may be separate records in the application yet become linkable through login challenges, funding transactions, support screenshots, or reused addresses. Keep identity records and educational history off chain. Do not put secrets or personal records into memo instructions or public metadata. If the product offers a shareable verifier, reveal only the credential fields the learner chose to share and explain that the public address remains observable.

FIELD NOTE 08

Write an honest disclosure and data inventory

For each field, record where it is stored, who can read it, how long it persists, whether it can be deleted, and what public chain observers can infer. Explain which token authorities can freeze, transfer, burn, update, or pause an asset. Distinguish protocol guarantees from issuer policy and gateway availability. Have another reviewer inspect the transaction and metadata, because privacy disclosures must match what the wallet signs and what RPC actually returns.

MAKE THE CONNECTION

A detail worth keeping.

Compare a standard SPL token and a Token-2022 mint using a fictional token with a permanent delegate and transfer hook. Build a permission table for holder, mint authority, permanent delegate, hook program, and token program; mark which actions are public to observers.

Work through an example

Review an asset metadata JSON document for direct identifiers and likely correlators. Then check the actual mint and token-account state on the intended cluster. A privacy claim must describe both published content and the public transaction graph.

Prepare a privacy and authority review for a fictional Token-2022 community token and the academy's Metaplex Core learning badge. Record the token program and extensions; for the Core asset, inspect the PermanentFreezeDelegate state, asset updateAuthority, collection update authority, and metadata URI. Inventory the public wallet, level, revision, opaque credential ID, and issuer signature, explain wallet-linkage and metadata-change risks, document lost-wallet replacement limits, and write an evidence-based learner disclosure. Compare the individual Core badge policy with Token-2022 NonTransferable: list transfer, burn, issuance, update, and metadata authorities, then justify the differences from current primary sources. Add a transfer-hook scenario: identify its mint-bound ExtraAccountMetaList, map original versus extra account privileges, and show how client construction, hook success, and hook rejection affect the final token state.

GUIDED PRACTICE · EXPERT

Do the work, one step at a time.

Use fictional addresses and disposable test data. Do not enter a recovery phrase or private key. Most exercises work on paper or with a local test; only a lesson that clearly says “read-only Devnet” makes a public network request.

Read the official Transfer Hook Interface example and identify the mint extension, hook program, Execute instruction, and optional extra-account metadata list.
For a fictional mint, write the PDA inputs for the ExtraAccountMetaList: the literal seed `extra-account-metas`, mint address, and hook program ID.
Draw the transfer instruction accounts, then mark which original accounts become read-only inside the hook and which declared extra accounts the hook needs.
Trace the client-built transfer through Token-2022 and the hook CPI; record how a missing extra account or a hook rejection reaches the caller.
Design a local test for success, missing required meta, and hook rejection; assert successful balance changes and unchanged token balances after either failure.
Build a two-column authority table for the frozen Core badge and a Token-2022 NonTransferable mint. Distinguish transfer, burn, mint, and metadata-update permissions, and note that neither design hides public wallet activity.

Before you move on, check your reasoning

List on-chain, off-chain, and third-party data fields.
Identify each authority and what token extensions permit it to do.
Write a concise learner disclosure that matches observed state.
Compare a frozen Core credential with a Token-2022 NonTransferable token: who can transfer, burn, issue, and update each one, and what wallet information remains public?

OPEN SELF-CHECK · UNGRADED

Pause and test your reasoning

A credential is public on-chain. Which metadata design best limits unnecessary disclosure?

Put the learner’s email, legal name, score, and exam answers in the metadata so employers can verify them.
Publish only the minimum credential facts needed for verification, such as issuer, level, course revision, issue date, and opaque identifier.
Encrypt the public fields with a key stored beside the asset and assume explorers cannot copy them.

Reveal one best answer and its explanation

One best answer: Publish only the minimum credential facts needed for verification, such as issuer, level, course revision, issue date, and opaque identifier.

Public chain data and durable metadata can be copied and indexed. A credential should prove only its defined claim; keep contact details, legal identity, answers, scores, and private learning history off-chain and out of public metadata.

Sources: Verifiable Credentials Data Model v2.0 · Persistence and Pinning

This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.

Never enter a recovery phrase or private key into a learning site or lesson exercise.

READ THE SOURCE

Go deeper in the official docs

Reviewed on 2026-09-28. Protocol documentation can change; check the linked page’s current version as you use this material.

Report an issue with this lesson

OPEN LEARNING

Keep learning at your own pace.

This lesson, its guided practice, and all six course lessons are open to everyone. Account-based checkpoints, exams, and saved progress will open when free accounts are ready.

Continue to the next lesson ↗