✳ SOLANA ACADEMYCourse overviewGlossary

Expert · LESSON 04 OF 07

4. Public data, privacy, and token design

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

The diagram separates public wallet history, the permanent freeze, immutable metadata, collection membership, asset-bound issuer proof, disclosure, and lost-wallet recovery.
4. Public data, privacy, and token design workflow. The diagram separates public wallet history, the permanent freeze, immutable metadata, collection membership, asset-bound issuer proof, disclosure, and lost-wallet recovery.
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.
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.
Permanent Freeze blocks transfer and burn. A Core Oracle may block transfer while allowing owner burns, but requires live account checks. Token-2022 NonTransferable blocks transfers while allowing burns and further minting. None hides wallet history.
Compare wallet-bound credential models. Permanent Freeze blocks transfer and burn. A Core Oracle may block transfer while allowing owner burns, but requires live account checks. Token-2022 NonTransferable blocks transfers while allowing burns and further minting. None hides wallet history.
Private exam records lead to an issuer-signed claim; the learner pays and signs the Core mint. Verification checks the owner, asset-bound signature, and plugin state. This frozen NFT cannot be transferred or burned; losing the wallet has no on-chain recovery.
From exam result to wallet-bound credential proof. Private exam records lead to an issuer-signed claim; the learner pays and signs the Core mint. Verification checks the owner, asset-bound signature, and plugin state. This frozen NFT cannot be transferred or burned; losing the wallet has no on-chain recovery.
Check the exact cluster and Oracle address, fetch finalized account state, decode every lifecycle result with the pinned SDK, compare transfer and burn behavior with the learner promise, and simulate both actions. Fail closed on a mismatch.
Audit a soulbound Oracle on chain. Check the exact cluster and Oracle address, fetch finalized account state, decode every lifecycle result with the pinned SDK, compare transfer and burn behavior with the learner promise, and simulate both actions. Fail closed on a mismatch.

Read the workflow

The wallet address and its public transaction history are visible on chain. The Core credential uses a permanent frozen plugin with no authority, an immutable-metadata plugin with no authority, and an AddBlocker plugin with no authority. The issuer signature covers the exact asset address and the achievement claim, so a copied metadata file on a different asset fails verification. Collection membership can change and is shown as current grouping, not proof of completion. Metadata should contain only public credential facts, never a learner’s email, legal name, exam answers, or private course history. Lost-wallet replacement needs a published policy.

  1. PUBLIC WALLET + HISTORY
  2. FREEZE PLUGIN ≠ UPDATE AUTHORITY
  3. ASSET + COLLECTION STATE
  4. DISCLOSURE + RECOVERY

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.

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

Read a text version: Compare wallet-bound credential models

Three columns compare the guarantees. Core PermanentFreezeDelegate makes each credential nontransferable and nonburnable; ImmutableMetadata and an address-bound issuer signature protect metadata and claim provenance, but a lost wallet has no on-chain move or burn recovery. An Oracle-based Core rule can reject transfers while leaving an owner burn available, according to documentation, but depends on an external lifecycle account. Decode its finalized values on the exact cluster and simulate; do not rely on its label. Token-2022 NonTransferable is set at mint initialization, blocks token transfers, permits owner or delegate burns, and does not revoke mint authority. Review wallet and marketplace support, metadata, and recovery separately. None of these models hides the wallet or its public transaction history.

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

Read a text version: From exam result to wallet-bound credential proof

Course and exam records remain off chain. The issuer signs a claim for the exact Core asset address, learner wallet, level, and curriculum revision. The learner’s wallet owns the new asset, pays the quote’s network fee, Core charge, and storage, then signs the creation transaction. The asset is born with PermanentFreezeDelegate frozen at authority None, ImmutableMetadata at None, and AddBlocker at None; no permanent burn or transfer delegate is allowed. A verifier checks the owner, address-bound issuer signature, plugin states, metadata URI, and reports collection grouping separately. Wallet activity is public, and IPFS CIDs do not guarantee availability. This asset cannot be transferred or burned; losing the signing wallet has no on-chain recovery.

  1. Private course record proves exam eligibility
  2. Issuer signs the exact asset, wallet, level, and revision
  3. Learner wallet pays and signs the Core asset creation
  4. Frozen asset locks transfer and burn; metadata URI is immutable
  5. Verifier checks owner, claim signature, plugins, and current grouping

Read a text version: Audit a soulbound Oracle on chain

The workflow starts with the exact cluster and published Oracle address, reads account bytes at finalized commitment while retaining provider and slot context, decodes the create, transfer, burn, and update fields with the pinned MPL Core SDK, compares transfer and burn values with the learner-facing policy, and simulates both actions on a disposable fixture. The final red warning states that a documented label is not live authority state. If documentation, decoded account state, or simulation disagree, stop issuance until the discrepancy is understood.

  1. EXACT CLUSTER + ORACLE
  2. FINALIZED ACCOUNT READ
  3. PINNED SDK DECODE
  4. COMPARE TRANSFER + BURN
  5. SIMULATE BOTH ACTIONS

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. This academy’s Devnet design creates an asset-level `PermanentFreezeDelegate` frozen with authority `None`, `ImmutableMetadata` with authority `None`, and `AddBlocker` with authority `None`; it rejects permanent transfer and burn delegates. The freeze prevents transfer and burn, ImmutableMetadata locks the on-chain asset name and metadata URI, and AddBlocker prevents later authority-managed plugin additions. AddBlocker does not block owner-managed plugins, so verify the permanent freeze and every plugin authority rather than relying on a label. This is stronger than non-transferability alone: a permanently frozen asset with no thaw authority cannot be moved to another wallet, and an ordinary owner burn is blocked. A `PermanentBurnDelegate` can burn even a frozen asset because its permanent plugin force-approves the burn, so the verifier rejects that plugin.

The learner cannot recover or destroy this same NFT after minting; losing the signing wallet leaves it inaccessible. Explain the wallet-loss and replacement policy before signing, and never imply that email or collection membership can restore on-chain ownership.

The issuer’s signature covers the exact Core asset address as well as the learner wallet, course, level, curriculum revision, and intended credential series. Collection membership is mutable grouping, not credential proof: the collection authority can detach an asset, while its address-bound signed claim, frozen state, and locked metadata remain verifiable. The verifier reports current grouping separately. 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 and signatures from current on-chain state.

Metaplex documents an Oracle-based soulbound option that can reject transfers while allowing an owner to burn, unlike this Academy's PermanentFreezeDelegate design, which blocks both. The Oracle is an external on-chain account, so verify its live lifecycle values on the exact target cluster instead of trusting an address label or a documentation example. Read the account at finalized commitment, record the RPC provider and context slot, decode create/transfer/burn/update with the pinned MPL Core SDK, inspect its controlling program and permissions, and simulate the relevant transfer and burn paths. Under the Oracle plugin, `Pass` means this check does not reject the lifecycle action; it is not a transfer-block signal. Other Core checks can still reject the action. For the observed `transfer=Pass`, do not claim that this Oracle enforces non-transferability. A structured evidence card below records this dated Devnet observation. It is historical cluster evidence, not a permanent protocol guarantee. Do not issue against that account for a non-transferability promise until the discrepancy is reproduced and resolved; fail closed if documentation, decoded state, and simulated behavior disagree.

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 transfer and burn behavior but does not itself lock metadata. ImmutableMetadata with authority `None` locks the asset name and URI; AddBlocker with authority `None` blocks later authority-managed plugin additions, though owner-managed plugins remain a distinct permission class. A collection update authority can change collection membership, and a collection Update Delegate can remove assets without the collection root authority signing. Inspect the asset’s permanent plugins, plugin authorities, current updateAuthority, collection delegates, metadata URI, owner, and issuer signature as separate evidence. This academy’s verifier authenticates the issuer-signed claim bound to the exact asset address; it reports the asset’s current collection grouping but does not require membership to remain unchanged. The wallet owner and transaction graph remain public. Model privacy, transferability, metadata control, membership, and claim provenance 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, ImmutableMetadata with authority `None` permanently locks the asset name and metadata URI; AddBlocker with authority `None` prevents later authority-managed plugin additions. Neither plugin controls off-chain gateway availability, so compare retrieved bytes with the CID and keep a recovery copy. A collection authority may remove or move an asset, changing its current grouping, but that does not rewrite the immutable metadata or the issuer signature. The credential claim therefore includes the exact asset address; a copied metadata document attached to a different asset address must fail verification. The public metadata identifies the asset and receiving wallet, level, curriculum revision, intended credential series, 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, plugin authorities, exact address-bound claim, 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. For this Academy’s frozen Core passport, even the learner cannot transfer or burn the same asset; a lost signing wallet has no on-chain recovery path. Disclose that permanent consequence and the separate replacement policy before the learner approves the transaction.

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 its exact address, owner, PermanentFreezeDelegate, ImmutableMetadata, AddBlocker, plugin authorities, updateAuthority, current collection grouping, metadata URI, and issuer signature. Inventory the public wallet, level, revision, intended series, opaque credential ID, and asset-bound claim; explain wallet-linkage and gateway-availability risks, document lost-wallet replacement limits, and write an evidence-based learner disclosure. Create a local duplicate asset at another address using a copy of the signed metadata and prove the verifier rejects it. Then detach the legitimate asset from the collection in a local fixture and prove verification still succeeds while the UI reports the new grouping. Compare the Core badge with Token-2022 NonTransferable and justify transfer, burn, issuance, update, and privacy properties 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 final token state. Before any learner signs a credential mint, write a short disclosure covering the asset’s non-transferable and non-burnable state, learner-paid network/Core/storage costs, public wallet linkage, metadata hosting, and what a lost wallet means. Do not promise email-based NFT recovery or reissuance unless an approved policy can actually provide it.

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. Unless a lesson explicitly says “read-only Devnet,” use paper or a local test and do not connect to a public network.

  1. Read the official Transfer Hook Interface example and identify the mint extension, hook program, Execute instruction, and optional extra-account metadata list.
  2. For a fictional mint, write the PDA inputs for the ExtraAccountMetaList: the literal seed `extra-account-metas`, mint address, and hook program ID.
  3. Draw the transfer instruction accounts, then mark which original accounts become read-only inside the hook and which declared extra accounts the hook needs.
  4. 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.
  5. Design a local test for success, missing required meta, and hook rejection; assert successful balance changes and unchanged token balances after either failure.
  6. Build a two-column authority table for the Core badge and a Token-2022 NonTransferable mint. For the Core asset, separate owner, payer, update authority, the frozen PermanentFreezeDelegate, ImmutableMetadata, AddBlocker, and issuer signature; verify that no permanent transfer or burn delegate exists.
  7. In a local verifier fixture, clone the signed metadata onto a different Core asset address and confirm address-bound signature validation rejects it. Then change the legitimate asset's current collection grouping while preserving its signed claim and plugins; confirm it stays valid and the verifier reports the new grouping.
  8. Audit the documented Metaplex Core transfer Oracle on the exact target cluster: fetch finalized account bytes, record the slot and provider, decode create/transfer/burn/update with the pinned MPL Core SDK, and compare the values with the documentation. Simulate transfer and owner-burn attempts from a disposable fixture; if the decoded transfer result is Pass, do not claim that the Oracle rejects transfers.

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

Practice 1 of 3

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

  1. Put the learner’s email, legal name, score, and exam answers in the metadata so employers can verify them.
  2. Encrypt the public fields with a key stored beside the asset and assume explorers cannot copy them.
  3. Publish only the minimum credential facts needed for verification, such as issuer, level, course revision, issue date, and opaque identifier.
Reveal the answer and 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 ↗

Practice 2 of 3

A credential mint uses Token-2022 NonTransferable. Which capability remains possible?

  1. Its owner or delegate may still burn it.
  2. NonTransferable also hides the owner address and prevents every burn instruction on the token.
  3. The NonTransferable extension prevents burning and every other token state change as well as transfers.
Reveal the answer and explanation

One best answer: Its owner or delegate may still burn it.

The extension blocks token transfers, not every operation or public observation. The Token Program still allows authorized burns, and public ledger activity remains observable. Review mint and delegate authorities separately from transfer policy.

Sources: Non-Transferable Tokens ↗ · Token Extensions ↗

Practice 3 of 3

A credential image is pinned to IPFS. Which storage statement is accurate?

  1. It pins the file forever.
  2. A CID verifies bytes, not long-term availability.
  3. Content addressing guarantees the image remains retrievable even if every provider stops pinning or serving it.
Reveal the answer and explanation

One best answer: A CID verifies bytes, not long-term availability.

A CID is derived from content and lets clients verify retrieved bytes. It does not guarantee that any provider will continue serving those bytes without persistence arrangements.

Sources: Content Identifiers (CIDs) ↗ · Persistence and Pinning ↗

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

Scored checkpoints and level exams are available online through a free account. They are not included in this pack.

READ THE SOURCE

Go deeper in the official docs

Reviewed on 2026-10-03. Protocol documentation can change; check the linked page’s current version when you reconnect.