I want to create a non-transferable token to represent an achievement. Which token standard is best for this?

If you’re building on an Ethereum/EVM-compatible chain, I’d recommend ERC-5192 (Minimal Soulbound NFTs) for a non-transferable achievement token.

ERC-5192 is an extension of ERC-721 specifically designed for NFTs that are locked to an account. It adds a standardized locked(tokenId) interface so applications can detect that the token is non-transferable, rather than merely discovering that transfers revert.

Why it fits an achievement

For example:

Alice completes a certification → your contract mints Achievement #123 to Alice → Alice can display it, but cannot transfer it to Bob. ERC-5192 gives you:

• Non-transferability: once locked, ERC-721 transfer operations must fail.
• NFT semantics: each achievement can have its own token ID and metadata.
• Detectability: wallets/dApps can use ERC-165 to recognize the soulbound interface.
• Simple implementation: it's deliberately a minimal extension rather than a large credential framework.
• Standardized behavior: the official EIP is finalized.

When I'd choose something else

ERC-6268 is specifically the non-transferability indicator for ERC-1155, so it's worth considering if you want many identical instances of an achievement rather than one unique NFT per achievement.

My default architecture: ERC-721 + ERC-5192, with metadata containing the achievement name, issuer, achievement date, description, and optionally evidence/credential information.

One important design question is revocation: if an achievement can ever be revoked (for example, a certification expires or is withdrawn), I'd consider ERC-5484 or an explicit revocation mechanism rather than making the token permanently immutable.

For an achievement token (commonly referred to as a Soulbound Token or SBT ), the best and most widely adopted standard is ERC-5192 (Minimal Soulbound NFTs).

Here is a breakdown of why this standard fits your use case, along with alternatives depending on your exact requirements:

• ERC-5192 (Minimal Soulbound NFTs): This is an extension of the standard ERC-721 NFT interface . It adds a simple locked(uint256 tokenId) function and ensures that any transfer attempts revert with an error once locked . It is lightweight, completely backward-compatible with regular NFTs , and allows marketplaces and wallets to natively recognize that the achievement cannot be moved.
• EIP-5484 (Consent-Based Soulbound Tokens): Another variation built on ERC-721 , but it specifically encodes who has the authority to burn or revoke the token (e.g., whether only the issuer, only the owner, or both can remove the soulbound credential). This is helpful if an achievement might need to be revoked later due to expiration or changing status.
• The "Overriding Transfer Functions" Approach (Custom ERC-721): Many projects simply deploy a standard ERC-721 contract and override the _beforeTokenTransfer (or _update ) hook to revert (revert("Soulbound: Token is non-transferable") ) whenever a transfer is attempted. While functional, it lacks the standardized signaling of ERC-5192, meaning external dApps and marketplaces won't cleanly identify it as soulbound until they inspect the code or test a transfer.

Recommendation

If you want clean marketplace and wallet compatibility without bloating your smart contract, ERC-5192 is the cleanest industry-standard approach for non-transferable achievements.

If you'd like, let me know:

• Which blockchain network you plan to deploy on (Ethereum, Polygon, Arbitrum, etc.)
• Whether you need the issuer to have the ability to revoke/burn the achievement later
• If you need a sample smart contract implementation to get started

I can tailor the recommendation or provide the code structure you need.

For representing an achievement, certification, or credential that shouldn't be tradeable, you want a Soulbound Token (SBT) —a non-transferable token permanently or semi-permanently bound to a user's digital identity.

The best token standard for this depends on your specific requirements for revocability, user consent, and simplicity.

Top Standards for Achievement Tokens

- **What it is:** An extension of the standard [ERC-721](https://eips.ethereum.org/EIPS/eip-721) NFT interface that adds a simple `locked(tokenId)` function and interface detection . When locked, all transfer functions automatically revert/throw an error.
- **Best for:** Most projects. Because it extends ERC-721, it instantly works with almost all existing NFT marketplaces, explorers, and wallets while gracefully signaling that the token cannot be moved.
- **Tradeoff:** It doesn't natively standardize who can unlock/burn the token or handle advanced revocation logic.[](https://eips.ethereum.org/EIPS/eip-5192) [[1]](https://eips.ethereum.org/EIPS/eip-5192)[[2]](https://www.cube.exchange/what-is/soulbound-token)

- **What it is:** Another extension of ERC-721 that introduces a `BurnAuth` enum . It specifies *who* has the authority to burn (destroy) the token—whether it's only the issuer, only the owner, both, or neither (immutable forever).
- **Best for:** Achievements where governance or consent matters . For instance, if a university issues a degree, they might want the power to revoke it if issued in error, or give the recipient the right to burn/discard an embarrassing credential.[](https://ethereum-magicians.org/t/erc-idea-address-derived-non-transferable-token-soulbound-token/28475) [[1]](https://ethereum-magicians.org/t/erc-idea-address-derived-non-transferable-token-soulbound-token/28475)[[2]](https://www.cyfrin.io/blog/what-is-a-soulbound-token)

- **What it is:** Writing a standard ERC-721 contract (using OpenZeppelin, for example) and overriding the transfer hook to outright reject any movement where `from` and `to` are not zero addresses (allowing minting and burning, but blocking peer-to-peer transfers).
- **Best for:** Maximum custom control if you don't mind writing a few lines of override logic without relying on specific SBT indexer extensions.

Which one should you pick?

• Choose ERC-5192 if you want the easiest, most widely recognized approach for a "badge" or "achievement" that can't be sold.
• Choose ERC-5484 if you need strict rules regarding whether the achievement can be revoked by the issuer or destroyed by the holder.

Would you like me to share a sample smart contract implementation using one of these standards, or do you need help defining revocation and burning rules for your specific achievement?

If you’re building on Ethereum or another EVM chain, ERC-5192 (Minimal Soulbound NFTs) is the best default for a non-transferable achievement token.

ERC-5192 extends ERC-721 with a standard locked(tokenId) interface. A locked token must reject transfers, while wallets and applications can detect that it is soulbound through ERC-165.

Which standard to choose?

• ERC-5192 — best general choice: Achievement badges, certificates, course completions, reputation, memberships, etc. It gives you normal NFT metadata plus an explicit, standardized non-transferability signal.
• ERC-5484 — choose if revocation/burning matters: It adds immutable burn-authorization rules, so you can specify whether the issuer, recipient, both, or neither can burn the achievement.
• ERC-4973 — alternative account-bound model: Worth considering if you specifically want an account-bound credential rather than an ERC-721-based NFT.
• ERC-5727 — for more sophisticated credentials: Useful when you need semi-fungible soulbound tokens or more complex credential/lifecycle functionality.

My recommendation

For something like:

“Alice completed Advanced Solidity Training” I would implement:

ERC-721 + ERC-5192

and mint one token directly to Alice's wallet. The token could contain metadata such as:

Achievement: Advanced Solidity Training
Issuer: Your Organization
Recipient: 0xABC...
Issued: 2026-08-29
Level: Advanced
Evidence: https://...

The important distinction is that ERC-5192 is an interface standard, not a complete credential system. You still need to decide things like whether the issuer can revoke an achievement, whether an address can receive the same achievement more than once, and what happens if the user loses their wallet.

If revocation is important, I'd lean toward ERC-5484 instead. Otherwise, ERC-5192 is the cleanest choice.

For representing an achievement (like a badge, certificate, or milestone) that shouldn't be traded or sold, the best choice is a Soulbound Token (SBT).

Specifically, ERC-5192 (Minimal Soulbound NFTs ) is widely considered the industry standard and the most practical approach for this use case.

Why ERC-5192 is the Best Choice

• Built on ERC-721: It is a lightweight extension of the standard ERC-721 NFT interface. This means it maintains full compatibility with existing NFT infrastructure, marketplaces, and developer tools.
• Explicit Non-Transferability: It introduces a simple locked(uint256 tokenId) function. When it returns true , all standard transfer functions are disabled and will revert/throw an error.
• Standardized Interface Detection: Using ERC-165 , wallets and decentralized applications (dApps) can programmatically recognize that the token is permanently locked and non-transferable.

Other Standards to Consider

• ERC-4973 (Account-Bound Tokens): Unlike ERC-5192 (which extends ERC-721), ERC-4973 tokens are bound directly to an account and do not implement standard transfer functions at all. It uses a different minting paradigm (often via signatures), but has less widespread marketplace and wallet integration than ERC-5192.
• ERC-5484 (Consensual Soulbound Tokens): Another extension of ERC-721, but it adds a BurnAuth parameter that specifies who has the authority to burn/revoke the token (the issuer, the owner, or both). This is useful if achievements need to be revocable by the issuing authority under certain conditions.

If you want to move forward, tell me:

• Do you want the issuing authority to be able to revoke/burn the achievement later?
• Are you deploying on Ethereum / EVM or another blockchain ecosystem?

I can recommend the exact smart contract template or implementation approach for your project.

For a non-transferable token representing an achievement (certificate, badge, credential, award, course completion, reputation marker), the best choice is usually a Soulbound Token (SBT) design. Blockchain Council The exact standard depends on how unique your achievements are and what features you need.

Recommended choices

1. ERC-5192 (Minimal Soulbound NFT) — best default choice

Use this if each achievement is a unique badge belonging to one person.

• Built as an extension of ERC-721
• Keeps NFT ecosystem compatibility (wallets, explorers, tooling)
• Adds a standard way to indicate the token is locked/non-transferable
• Good for: diplomas, certifications, contributor badges, awards, achievements

Example:

"Completed Advanced Solidity Course — issued to Alice — cannot be sold or transferred." This would be my default recommendation for most achievement systems.

---

2. ERC-5484 — best if you need revocation rules

Use this when the issuer needs explicit control over the lifecycle.

Useful for credentials like:

• Professional certifications
• Licenses
• Memberships
• Training certificates

It lets you define who can burn/revoke the token (issuer, holder, both, or neither).

Example:

A university can revoke a certificate if it was issued incorrectly.

---

3. ERC-1155 + non-transferable extension — best for large-scale badges

Use this if many people receive the same achievement.

Example:

• "Attended 2026 Developer Conference"
• "Completed Level 3 Training"
• "Season 5 Champion"

ERC-1155 is more efficient for issuing many copies of the same badge type, and standards such as ERC-6268 address signaling non-transferability for ERC-1155-style tokens.

---

Quick decision table

Parse Ethereum Improvement Proposals## A few design decisions to make before building

1. Can the issuer revoke it?

• Permanent achievement → no burn/revoke
• Credential/license → probably yes

2. What happens if the user's wallet is lost?

• A truly soulbound token cannot simply be transferred to a new wallet.
• Consider a recovery process or a claim-based reissuance mechanism.

3. Should the achievement be public?

• Public metadata: easy verification
• Private data: store only a hash or use verifiable credentials

For a typical "achievement badge" product on an EVM chain (Ethereum, Base, Polygon, Arbitrum, etc.), I would choose ERC-5192 with carefully designed revocation/recovery logic.

To represent a non-transferable achievement (such as a certification, attendance badge, or milestone completion), Soulbound Tokens (SBTs) —specifically implemented as ERC-5192 (Minimal Soulbound NFTs) or via a modified ERC-721 —are the best and most widely adopted choice.

These are often referred to as Account-Bound Tokens (ABTs) because they bind directly to a specific user's wallet address and cannot be traded or sent to someone else.

Top Standards to Consider

- **What it is:** An extension of the standard **[ERC-721](https://google.com/goto?url=CAESSgHrOzAVlyxKUq327El9JgVtPQnqu3svJjkIj-FEp4zZcu-DMTzoylxNrhum2oXHLoggNYefzIJD0H04tY_owoDpDw5TddAvcJp-)** NFT interface that adds a simple `locked(uint256 tokenId)` state and standard event logs. When locked, all transfer functions throw an error.
- **Why it's great:** It is lightweight, widely recognized by marketplaces/wallets via ERC-165 interface detection, and explicitly signals to frontends that the achievement belongs strictly to that address and cannot be moved.[](https://google.com/goto?url=CAESSgHrOzAV9VbPTGI6OA94MXIo_td0FD9dRl5vTarsGbJ_5hW3UwvHjX5b2iYPfDSfD45Lya8ZTmDvMp4Emej-ZHMmGFPng69TZIzB) [[1]](https://google.com/goto?url=CAESSgHrOzAV9VbPTGI6OA94MXIo_td0FD9dRl5vTarsGbJ_5hW3UwvHjX5b2iYPfDSfD45Lya8ZTmDvMp4Emej-ZHMmGFPng69TZIzB)[[2]](https://google.com/goto?url=CAESVAHrOzAVMi4hEtkLVCHOmZd0QDFNxYkhfc8yhCLdu0VMYCEZF7wdGNvi3s2tGKH4ltlttgNrITLsvBKBHuLf85yuBSx1cXCE7rMUGXRIeuQm58bxXg)[[3]](https://google.com/goto?url=CAESdAHrOzAVbKqOI7HaqdiZ6am0ifWlg8tcK5bMriDk7Ey7X64rupt7ZplAlhvYL5ekhL_jp_FHe3EVHJIqUblqFFlCqRHIIxEt0kBmcuKtSZWvdvDzWcGBW93A1gqfbzQ2uozxIiSEpuIkaeYD0N8WcFAiNLfJ)[[4]](https://google.com/goto?url=CAESWgHrOzAVFcb1B3oVWpbCaYA1n7bJfe4EhmsWsZZHDv02dMrPI_XGRza9clRNCGUUOyhinvNqZ86SAbxyb553qdcD7sLfbrlHZGcZ5W5DKvon5vf5zFqUilkh3A)

- **What it is:** A standard ERC-721 contract where you override the internal transfer hooks (like `_beforeTokenTransfer` or `_update` depending on your OpenZeppelin version) to revert/fail on any transfer attempts that aren't a mint (0 → address) or a burn (address → 0).
- **Why it's great:** Most developers choose this route because OpenZeppelin doesn't have a mandatory native wrapper for every specialized SBT spec, giving you full control over whether achievements can be revoked (deleted by the issuer) or permanently static.[](https://google.com/goto?url=CAESiAEB6zswFafJG_TP7w7peTJXvcKu2F1mmSOvTiqpVjxHZOFfyu3HofI8ADDFfbZxm9AQ9I7QDuZ_5qpnd3yGhe-0OfIGgPAkPV-wVmr9nFqrjbLb5R8M2CxZ5d9LTRHiciCmt7tbTU914ldV-dQJXU1pK3pPOywUCNxCUChvUdsPC1DNKOwjJm-m) [[1]](https://google.com/goto?url=CAESiAEB6zswFafJG_TP7w7peTJXvcKu2F1mmSOvTiqpVjxHZOFfyu3HofI8ADDFfbZxm9AQ9I7QDuZ_5qpnd3yGhe-0OfIGgPAkPV-wVmr9nFqrjbLb5R8M2CxZ5d9LTRHiciCmt7tbTU914ldV-dQJXU1pK3pPOywUCNxCUChvUdsPC1DNKOwjJm-m)[[2]](https://google.com/goto?url=CAESYwHrOzAVMUHNF6s_9P4dHbJByh0-UyqSUTN5XBhnN7kQQq22_mDXHdtUeG45ISR33PAZT14-yLsP9FlROWngmZ6WwrCic76uyZ8bLe5Yix9NWKwPtf72SIFThxBiTih3VW-xMw)[[3]](https://google.com/goto?url=CAESbAHrOzAViiGf3QhEqsmebHzLaZT14TfbamKOyNfwVUp57fabAy-Jcc2k5xy3uPpxTl2hOoVyPFcMErp6mEarUdkTU6Vula3GHLl07WOKuSShtVzuTr9aytCWK9GWgrqKv3NkBYdiRvAOSTP7WQ)[[4]](https://google.com/goto?url=CAESTQHrOzAVN-3djccvGR-5fndWVofdD1uh3wiairNk1ARd1-Kcp04MKcIgAfqfUP24bAwMsr8pJe-tGYYaSyne3VDzgvNmeQ1HM1w8Uc37)[[5]](https://google.com/goto?url=CAESTwHrOzAVjwlg1m03gcXMtKsUickfpNnNkLt_UMhs8kxLFpbJg7__huyUQS5GoxFH5f1pQl1JxNDsO09DZB5O_GPPcYjGQAl5sGlv2vSai1s)

- **What it is:** An extension of ERC-721 that defines *who* has the authority to burn (revoke) the token, agreed upon mutually by the issuer and receiver at the time of minting.
- **Why it's great:** Ideal if your achievement requires a trust framework where the user knows ahead of time whether the issuer can strip the credential (e.g., if a professional license expires or is revoked for malpractice).[](https://google.com/goto?url=CAESSgHrOzAVtt_Oz3nXW13gA9MFPvGa-3DjIkvqs-1GZhvFnquK8bfDR-R-FrvGr3FgmtPpJPZD0Z-smyOH4QOu8Bn2j4KWN4OO_nZk) [[1]](https://google.com/goto?url=CAESSgHrOzAVtt_Oz3nXW13gA9MFPvGa-3DjIkvqs-1GZhvFnquK8bfDR-R-FrvGr3FgmtPpJPZD0Z-smyOH4QOu8Bn2j4KWN4OO_nZk)[[2]](https://google.com/goto?url=CAES0AEB6zswFS03p85Tqbut3kE4YkoydcV4-ePkRyMjSGqO2euwdqbvzy7-nTFKkoZjPOYa9V1dUnSN_XYW3HHYbMjBUZ_g30q3Dp4Wz14KCqszN7i_iPufoD4kXhh8LAxN-nxQ_LGzS_kc40lyxXKgW_3g4VPpmNpkqmotgcjaUyph4st48wzb96PCofY8_byEOf30Xlo3r3MxaDznF9zE5-OXuqza4wLa4YDZNKUCbwapp3Sv373aFjylhWIuuTbhbyleZA-MOOgJ9z0Ei9ssjj4M)[[3]](https://google.com/goto?url=CAESVwHrOzAVc3BgRtssCm3-do_2R63Q9BvxHLLMcSyQFHJhufz1qr99Kkr1r8UhJ7QMDkWAFmQDqlLclCceZaNRr_mHycefFatFZYWtTxE5cVbnRvQmlB4Yzg)[[4]](https://google.com/goto?url=CAESbAHrOzAViiGf3QhEqsmebHzLaZT14TfbamKOyNfwVUp57fabAy-Jcc2k5xy3uPpxTl2hOoVyPFcMErp6mEarUdkTU6Vula3GHLl07WOKuSShtVzuTr9aytCWK9GWgrqKv3NkBYdiRvAOSTP7WQ)

Recommendation Summary

• If you just want a standard, clean badge that platforms instantly recognize as non-transferable, use ERC-5192.
• If you want maximum flexibility over how it's coded, write a custom OpenZeppelin ERC-721 override that disables transfers post-mint.

To help narrow down the implementation approach, could you tell me:

• Do you need the ability to revoke/delete the achievement later if details change?
• Are you deploying on Ethereum/EVM , or another network?

For an achievement that should be non-transferable and tied to a specific wallet, I’d use ERC-5192 (Minimal Soulbound NFTs) on an EVM-compatible chain.

ERC-5192 is an extension of ERC-721 specifically designed for soulbound NFTs. It adds a standardized locked(tokenId) interface so wallets and applications can detect that the NFT is permanently non-transferable, rather than merely discovering that transfers revert.

Recommended architecture

ERC-721 + ERC-5192

For example:

Alice completes your certification → your contract mints Achievement #123 to Alice → the token remains permanently bound to Alice's address. You can put normal NFT metadata on it, such as:

• Achievement name
• Description
• Issuer
• Date earned
• Achievement level
• Evidence/reference
• Image or badge artwork

When I'd choose something else

ERC-6268, for example, provides a non-transferability indicator specifically for ERC-1155 tokens, which can make more sense if your achievement system is highly repetitive or semi-fungible.

One important design issue: a soulbound NFT is bound to a wallet, not necessarily to the person. If someone loses their wallet, you need a policy for reissuing/recovering the achievement. Also decide whether achievements can be revoked—ERC-5192 itself is intentionally minimal and doesn't prescribe a revocation system.

If you tell me the blockchain you're using (Ethereum, Base, Polygon, etc.) and whether achievements need revocation, I can recommend the exact contract pattern.

When I'd choose something else

For representing an achievement, credential, or badge on-chain, the best approach is using a Soulbound Token (SBT) —a non-transferable digital asset permanently tied to a specific wallet address.

Instead of creating a custom smart contract that simply throws an error when a transfer is attempted, the Ethereum ecosystem has established official, interoperable standards. The most widely adopted and practical standards for achievement tokens are detailed below:

1. ERC-5192: Minimal Soulbound NFTs (Recommended for Simplicity)

• What it is: An extension of the standard ERC-721 NFT interface. It adds a single function, locked(uint256 tokenId) , which lets wallets and marketplaces instantly query whether a token is locked (non-transferable) or unlocked.
• Why it’s best for achievements: It retains full compatibility with existing ERC-721 infrastructure (like marketplaces, indexing tools, and wallets), but standardizes the signal that the token cannot be moved. Standard tools instantly recognize it as a "soulbound" badge.

2. ERC-5484: Consensual Soulbound Tokens (Best if Revocability/Key Rotation is Needed)

• What it is: Another extension of ERC-721, but it introduces a BurnAuth attribute that explicitly defines who has the authority to burn (destroy) the token—the issuer, the owner, or both.
• Why it’s best for achievements: Achievements sometimes need a lifecycle mechanism. If a user loses access to their private keys and needs to migrate to a new wallet, or if an issuing authority needs to revoke a credential due to an expiration or error, ERC-5484 provides a trust-minimized, standardized way to handle burning and re-issuing.

3. ERC-4973: Account-Bound Tokens (Best for "Claimable" Badges)

• What it is: Often referred to as ABTs, this standard creates non-transferable tokens that function independently of the traditional ERC-721 transferFrom mechanics. It often utilizes EIP-712 signatures, allowing an issuer to sign an achievement badge off-chain and letting the user "claim" (mint) it directly to their wallet.
• Why it’s best for achievements: It mimics an "invitation/claim" flow where the recipient actively accepts the achievement into their digital showcase.

Summary Recommendation

• Use ERC-5192 if you want the easiest, lightest implementation that works out-of-the-box with standard ERC-721 tooling.
• Use ERC-5484 if you need governance over who can revoke or burn the achievement later on.

To help narrow down the technical setup, tell me:

• Do you want the user to claim/mint the achievement themselves, or should your platform airdrop/push it to them?
• Do you need the ability to revoke or update the achievement later?

For a non-transferable token representing an achievement (a badge, certificate, credential, rank, course completion, award, etc.), the best fit on an EVM-compatible blockchain is usually ERC-5192 (Minimal Soulbound NFTs).

Recommended: ERC-5192 (Soulbound Token)

ERC-5192 is a lightweight extension of ERC-721 designed specifically for non-transferable NFTs. It adds a locked(tokenId) interface so wallets and applications can detect that a token is permanently bound to an account, rather than merely discovering that transfers fail.

Typical flow:

1. A user earns an achievement.
2. Your issuer contract mints an ERC-5192 token to their wallet.
3. The token remains tied to that wallet and cannot be transferred to someone else.

Example use cases:

• University diploma
• Employee certification
• Hackathon award
• Course completion badge
• Community reputation badge
• Event participation credential

Alternatives to consider

Ethereum Improvement Proposals ChainScore Labs## Design questions to decide before implementation

• Can the achievement ever be revoked? If yes, consider adding controlled burn/revocation logic (for example, an ERC-5484-style model).
• What happens if a user loses their wallet? A truly soulbound token cannot simply be transferred to a new wallet. You may need a recovery or reissuance mechanism.
• Do you need one achievement per person? ERC-5192 does not automatically enforce “one token per address”; your contract logic must enforce uniqueness if required.
• Do many users receive the same badge type? If you need large-scale identical credentials rather than unique NFTs, an ERC-1155-based approach with non-transferability signaling may be more appropriate.

For a normal “Alice completed X and should permanently own a proof of that achievement” scenario, I would choose ERC-5192 + ERC-721 metadata + carefully designed revocation/recovery rules.