Soulbound Tokens for AI Agents: A Technical Guide

Last updated: January 2026 · 10 min read

Most AI agent identity systems have a problem: you can sell your reputation. Build trust for a year, transfer the credential to someone else, and they inherit everything you earned. Soulbound tokens fix this. Here’s how they work and why they matter for AI agents.

What Are Soulbound Tokens?

A soulbound token (SBT) is a blockchain token that cannot be transferred once it’s minted. It’s permanently bound to a single wallet address. You can’t sell it, trade it, or give it away. The only options are to keep it or burn it.

The concept was introduced by Ethereum co-founder Vitalik Buterin in a May 2022 paper co-authored with economist Glen Weyl and lawyer Puja Ohlhaver. They proposed SBTs as the foundation for a “decentralized society” where reputation, credentials, and affiliations are publicly verifiable but non-tradeable.

The technical standard is ERC-5192, finalized in 2022. It’s an extension of ERC-721 (the standard NFT contract) that adds a single critical feature: a locked() function that returns true for tokens that cannot be transferred.

Why Transferable Identity Is a Problem

Consider how most AI agent identity systems work today. An agent registers, receives a credential or NFT, builds a track record, accumulates vouches or reputation scores. That identity becomes valuable.

Now imagine that identity is transferable. A few scenarios:

Reputation laundering. A bad actor builds a clean identity over months, then sells it to someone who wants to scam without starting from zero trust.

Identity markets. Aged accounts become commodities. “6-month-old agent identity, 50 vouches, $500.” We already see this with social media accounts and domain names.

Credential arbitrage. Buy a verified identity, use it for one high-value fraudulent transaction, disappear. The identity’s reputation absorbs the damage.

These aren’t hypothetical. They’re exactly what happens with every transferable reputation system. eBay seller accounts get sold. Aged Reddit accounts trade on marketplaces. The moment reputation becomes transferable, it becomes a market.

How Soulbound Tokens Solve This

With soulbound tokens, the identity and the wallet are permanently linked. If you want the reputation, you need the wallet. If you want the wallet, you need the private keys. The keys are the identity.

This creates different economics:

You can’t sell reputation without selling control. Handing over private keys means handing over everything — all assets, all permissions, all future actions. The buyer becomes indistinguishable from the original owner, with full liability.

History is permanent. Every transaction, every vouch, every flag is tied to that specific wallet forever. You can burn the identity, but you can’t edit the history.

Transfer detection is trivial. If a soulbound token suddenly appears in a different wallet than it was minted to (which shouldn’t be possible), that’s an immediate red flag. The contract makes unauthorized transfers visible by design.

ERC-5192: The Technical Standard

ERC-5192 is minimal by design. It extends ERC-721 with just two additions:

1. The locked() function. Returns true if the token is soulbound, false if it’s transferable. Simple boolean check.

2. The Locked event. Emitted when a token’s transferability status changes. For permanently soulbound tokens, this fires once at mint and never again.

The standard deliberately doesn’t specify how to make tokens non-transferable — it just defines how to signal that they are. Implementations can override the transferFrom function to revert, or use other mechanisms. The interface is what matters for interoperability.

// ERC-5192 Interface
interface IERC5192 {
    // Emitted when the locking status changes
    event Locked(uint256 tokenId);
    event Unlocked(uint256 tokenId);
    
    // Returns true if the token is non-transferable
    function locked(uint256 tokenId) external view returns (bool);
}

SBTs vs. Verifiable Credentials

Some AI agent identity systems use W3C Verifiable Credentials instead of blockchain tokens. These are cryptographically signed documents that can prove claims about an entity. They’re the foundation of systems like Billions Network and parts of Vouched‘s stack.

Verifiable Credentials have advantages: they’re privacy-preserving (you can selectively disclose), they work off-chain, and they follow W3C standards with broad tooling support.

But they’re not inherently non-transferable. A credential is a signed document. If you share the document (and any required keys), someone else can present it. Revocation exists, but it’s reactive — the issuer has to notice misuse and revoke. With SBTs, transfer prevention is proactive and enforced at the protocol level.

The two approaches aren’t mutually exclusive. A system could use SBTs as the identity anchor and Verifiable Credentials for specific attestations about that identity.

The ERC-8004 Gap

ERC-8004 is the emerging Ethereum standard for AI agent identity, backed by Ethereum Foundation, Coinbase, Google, and MetaMask. It defines how agents register on-chain, store metadata, and receive validation.

But ERC-8004 uses regular ERC-721 NFTs. The identity tokens are transferable by default. The standard explicitly separates “ownership” from “control,” allowing agent identities to be bought and sold like any other NFT.

This is a design choice, not an oversight. The authors wanted flexibility — some use cases might legitimately require transferable agent identities (company acquisitions, infrastructure migrations). But for reputation-based trust systems, it’s a vulnerability.

The solution is layering: use ERC-8004 for discoverability and standard compliance, add ERC-5192 for non-transferability. The SBT doesn’t replace the agent registry — it anchors it to a specific wallet permanently.

Implementation: A Working Example

Here’s a simplified soulbound identity contract for AI agents. This is based on production code deployed on Base mainnet.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract AgentIdentity is ERC721, Ownable {
    
    // ERC-5192 events
    event Locked(uint256 tokenId);
    
    // Track original minter for continuous ownership proof
    mapping(uint256 => address) public originalMinter;
    mapping(uint256 => uint256) public mintTime;
    
    constructor() ERC721("AgentIdentity", "AGENTID") {}
    
    function mint(address to, string calldata did) external onlyOwner {
        uint256 tokenId = uint256(keccak256(abi.encodePacked(did)));
        _mint(to, tokenId);
        originalMinter[tokenId] = to;
        mintTime[tokenId] = block.timestamp;
        emit Locked(tokenId); // Signal soulbound status
    }
    
    // ERC-5192: Always returns true (permanently soulbound)
    function locked(uint256 tokenId) external view returns (bool) {
        require(_exists(tokenId), "Token does not exist");
        return true;
    }
    
    // Block all transfers
    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 tokenId,
        uint256 batchSize
    ) internal override {
        require(from == address(0) || to == address(0), 
            "Soulbound: Transfer not allowed");
        super._beforeTokenTransfer(from, to, tokenId, batchSize);
    }
    
    // Allow owners to burn their identity (right to disappear)
    function burn(uint256 tokenId) external {
        require(ownerOf(tokenId) == msg.sender, "Not token owner");
        _burn(tokenId);
    }
    
    // Check if current owner is original minter
    function hasContinuousOwnership(uint256 tokenId) external view returns (bool) {
        return ownerOf(tokenId) == originalMinter[tokenId];
    }
    
    // Get identity age in seconds
    function identityAge(uint256 tokenId) external view returns (uint256) {
        require(_exists(tokenId), "Token does not exist");
        return block.timestamp - mintTime[tokenId];
    }
}

Key implementation details:

DID-based token IDs. The token ID is a hash of the DID string. Same DID always produces the same token ID, making lookups deterministic.

Original minter tracking. The originalMinter mapping stores who first received the token. Combined with ownerOf(), you can verify continuous ownership — the identity has never changed hands.

Mint time recording. Timestamp of creation enables age-based trust weighting. A 2-year-old identity carries more weight than a 2-day-old one.

Right to disappear. Owners can burn their own identity. This is a feature, not a bug — people (and agents) should have the ability to exit. The history remains visible on-chain, but the identity is gone.

What SBTs Don’t Solve

Soulbound tokens aren’t magic. They solve the transfer problem, but other challenges remain:

Key compromise. If someone steals your private keys, they control your soulbound identity. The token doesn’t transfer, but the attacker has the keys. Solutions exist (social recovery, multisig, MPC wallets), but they add complexity.

Identity rental. You can’t sell a soulbound identity, but you could rent access. “Pay me $100/month and I’ll sign transactions for you.” The identity stays in my wallet, but you’re effectively using it. Detection requires behavioral analysis, not just on-chain data.

Sybil attacks. Nothing stops someone from creating many wallets and minting many identities. Each identity is soulbound, but an attacker can still spin up hundreds of fresh identities. Defenses require additional mechanisms — staking, vouching from established identities, time-weighted trust.

Privacy. Everything on-chain is public. Your entire history is permanently visible. For many use cases this is fine or even desirable, but it’s a tradeoff. Hybrid approaches using off-chain attestations with on-chain anchors can help.

Why This Matters for AI Agents

AI agents are going to need identity infrastructure. They’ll transact, accumulate reputation, make commitments, and interact with other agents and humans. The question is what kind of identity system they get.

Transferable identity systems will create identity markets. Aged agent accounts will be bought and sold. Reputation will become a commodity disconnected from the entity that earned it.

Soulbound systems create different incentives. If you can’t sell your reputation, you have to protect it. If your history is permanent, you have to live with it. If your identity is bound to your keys, you are your keys.

Neither approach is “right” in absolute terms. But if you believe trust should be earned rather than purchased, non-transferable identity is the foundation.